ABSTRACT
THE CONCURRENCY PARADOX: In high-throughput inventory systems (10k+ RPS), traditional RDBMS locking strategies (Row-Level Locking, SELECT FOR UPDATE) become catastrophic bottlenecks. The latency gap between "Reading Inventory" and "Committing Decrement" creates a race condition window where multiple threads perceive the same availability.
This system bypasses disk-based IO blocking by implementing a Memory-First Architecture. Inventory logic is decoupled from persistence. State is managed via a Redis Distributed State Machine using atomic Lua scripting, ensuring strict serialization of concurrent requests at the microsecond level.
INITIALIZE_SIMULATION_SEQUENCE
DATA_STRUCTURE_MAPPING
| COMPONENT | DATA_STRUCTURE | RATIONALE |
|---|---|---|
| RESERVATIONS | REDIS ZSET (Sorted Set) | O(log N) expiry cleanup via ZRANGEBYSCORE. |
| PERSISTENCE | REDIS LIST (Queue) | Atomic RPUSH/BLPOP for non-blocking write buffer. |
| RATE_LIMIT | REDIS STRING + TTL | Fixed-window counters with automatic key eviction. |
| LOCKING | LUA SCRIPTING | Server-side atomicity; eliminates network round-trips. |
CONCEPT: WHY ACID FAILS
In a standard PostgreSQL transaction (`SELECT FOR UPDATE`), the database locks the specific row until the write commits.
At 10,000 requests/sec, these locks stack up. The DB spends more time managing lock queues than writing data.
THE FIX: We move the "Lock" to Redis (RAM). Redis operations are atomic by default (single-threaded event loop). We can check and decrement inventory in 0.005ms, whereas a DB lock takes 5-10ms.
PERFORMANCE_METRICS
* Benchmarked via k6 (local docker network). Values represent average performance under sustained load of 500 VUs.
SCHEMATIC_01: DATA_FLOW
FIG 1.0: TRANSACTION FLOW
User requests traverse the Load Balancer to the API Gateway. Atomic locks are acquired in Redis. Success triggers an async job to the Worker Node for SQL insertion.
SCHEMATIC_02: COMPONENT_TOPOLOGY
FIG 1.1: COMPONENT TOPOLOGY
The "Two-Tier" state system. Hot State lives in Redis (Master/Replica) for low-latency locking. Cold State lives in PostgreSQL for ACID compliance and reporting. The background "Reaper" worker ensures loose consistency becomes eventual consistency.