Home Project Architecture Presentations Team Admin / Login
Software Engineering Project · TIET · 2026

CHAOSLAB

Declarative Recovery-Correctness Analysis
for Distributed Microservices

ChaosLab verifies whether distributed applications recover to a correct business state after controlled failures — not just whether the services come back up.

🧩
Microservices
Failure
♻️
Recovery
🔎
Evidence
PASS / FAIL

"Healthy" isn't the same as "correct."

After a chaos experiment, a distributed system can report every service as up, every health check green, and every pod running — while the underlying business state is quietly wrong. Liveness checks don't catch this. ChaosLab does.

post-recovery-state.log
$ kubectl get pods --namespace=boutique
✔ all 11 services Running
✔ readiness probes: 11/11 passing
$ chaoslab verify --experiment checkout-partition-01
✘ duplicate payment charge detected (order #48213)
✘ inventory not decremented after confirmed order
⚠ order state = "CONFIRMED", payment state = "REFUND_PENDING"
VERDICT: RECOVERY_INCORRECT
×2

Duplicate Payment

A retried request after a network partition charges the customer twice, even though every service reports success.

Missing Inventory Deduction

An order is confirmed, but a crash during recovery leaves stock levels untouched — silently overselling later.

Incorrect Order State

The order service and payment service disagree about what happened, and nothing surfaces the contradiction.

Inject failure. Let it recover. Prove the outcome.

ChaosLab sits between a chaos-engineering tool and the application under test, correlating what actually happened against a declarative definition of what should have happened.

Chaos Mesh injects controlled failure
Distributed Application e.g. Online Boutique
Recovery system self-heals / restarts
ChaosLab observes & analyzes
Evidence Correlation logs, DB state, traces
Declarative Oracle expected business invariants
Recovery Correctness Verdict PASS / FAIL + evidence

What ChaosLab actually does

Fault injection is supporting infrastructure. These are the parts that make recovery correctness verifiable.

§

Declarative Recovery Oracles

Business-level invariants — "an order's payment and inventory state must always agree" — expressed declaratively, not hard-coded per test.

Evidence Correlation

Logs, database snapshots, and OpenTelemetry traces are correlated across services to reconstruct exactly what happened during recovery.

Business Invariant Verification

Checks outcomes against real business rules, not just HTTP status codes or pod readiness.

Controlled Fault Experiments

Reproducible failure scenarios — network partitions, pod kills, latency injection — driven through Chaos Mesh.

Ground-Truth Mutation Testing

Deliberately broken recovery paths validate that ChaosLab's oracles actually detect incorrect state, not just healthy ones.

Recovery Correctness Reports

A structured PASS/FAIL verdict backed by the evidence trail that produced it — auditable, not a black box.

How the pieces fit together

A birds-eye view of the ChaosLab system. See the full breakdown on the Architecture page.

User
ChaosLab API
Experiment Manager
Oracle Engine
Evidence Collector
Correlation Engine
Verdict Generator
External Systems
Chaos Mesh Online Boutique Database Logs OpenTelemetry

Who's building this

AS

Arjan Singh Sawhney

1024170074
HG

Himanshi Gupta

1024170079
HM

Harsith Mahay

1024170075
PS

Parth Singh

1024170086
Planning
In Progress
Evaluation

The recovery-correctness engine (Oracle Engine, Evidence Collector, Correlation Engine, Verdict Generator) is under active development and not yet implemented. This website currently reflects the approved project plan and design — not a working analysis engine.