A Kafka-based order processing platform demonstrating failure-resilient inventory handling using Redis Lua scripts.
This repository focuses on orchestration, not data correctness.
This service:
- Consumes Kafka events
- Orchestrates order and payment flow
- Delegates inventory correctness to Redis Lua
Inventory is never mutated in application code.
1️⃣ System-Level Architecture (Big Picture) 📌 What this communicates
-
Clear separation of responsibilities
-
Inventory correctness isolated
-
Event-driven thinking
2️⃣ Inventory State Machine (Correctness Focus) 📌 What this communicates
-
Deterministic inventory lifecycle
-
Explicit rollback & compensation
-
No hidden transitions
3️⃣ Failure Scenario: Kafka Replay Protection 📌 What this communicates
-
Real production failure handling
-
Idempotency awareness
-
Kafka maturity
4️⃣ Failure Scenario: Payment Failure Rollback 📌 What this communicates
-
You designed for negative paths
-
No inventory leaks
-
Clean rollback
Inventory consistency is enforced using a dedicated repository:
➡ redis-inventory-guard
Why?
- Atomic stock operations
- Retry & replay safety
- Crash resilience
- Clear separation of concerns
OrderCreated (Kafka) ↓ Inventory Reserve (Redis Lua) ↓ Payment Processing ↓ Commit or Release Stock (Redis Lua)
Kafka guarantees delivery.
Redis guarantees correctness.
- Thin Kafka consumers
- No business logic in listeners
- Idempotent by design
- Failure-first thinking
- Easy recovery & replay
✔ Consumer crashes → Kafka replay
✔ Redis retries → Lua idempotency
✔ Payment failure → stock release
✔ Partial failures → compensation supported
This approach:
- Scales horizontally
- Survives retries & replays
- Is easy to reason about under failure
- Mirrors real production architectures
Inventory correctness is enforced at the data layer,
not scattered across services.
- Backend/platform engineers
- Distributed systems practitioners
- Kafka-based architectures
- Engineers designing for correctness, not demos