01
Stock Gate
Redis
The stock decision must happen fast and atomically before valid checkout work enters the asynchronous path.
stock validation + decrement
Architecture Lab
Stock is decided before the database feels pressure.
The thesis architecture separates the fast stock decision from the durable write path. Redis protects stock atomically, RabbitMQ buffers valid checkout work, workers persist final state into PostgreSQL, and centralized observability keeps the asynchronous system explainable.
Frontend checkout intent enters the backend API before the protected stock-safe path begins.
Redis validates and decrements stock before RabbitMQ accepts valid checkout work.
Workers write final state to PostgreSQL while LGTP exposes logs, metrics, traces, and health signals.
Request Map
Map the pressure, not a timeline.
The architecture is organized by responsibility: request entry, stock gate, pressure buffer, controlled persistence, and an observability layer that wraps the whole route.
entry zone
01
Frontend
Checkout intent
Buyer starts checkout from the storefront or flash sale campaign.
02
Backend API
Request entry
The API receives the checkout intent before the stock-safe path begins.
atomic gate
Redis
Stock validation and decrement happen atomically before queueing valid work.
persistence zone
05
Worker
Async processor
Workers consume queue messages and move checkout work toward final persistence.
06
PostgreSQL
Source of truth
Final transaction and order state are written durably after the protected flow.
pressure buffer
RabbitMQ
Valid checkout work is queued so PostgreSQL is not hit by every concurrent request at once.
LGTP Observability
Metrics, logs, traces, and dashboards expose bottlenecks, failures, and recovery signals. Prometheus records metrics, Loki stores logs, Tempo captures traces, and Grafana visualizes system health.
Pressure Zones
The system is not a stack. It is a pressure-control route.
02
Pressure Buffer
RabbitMQ
Valid checkout messages are queued so PostgreSQL is not forced to absorb every concurrent request directly.
publish valid work only
03
Controlled Persistence
Worker + PostgreSQL
Workers consume queued checkout work and write final transaction state into PostgreSQL as the durable source of truth.
final transaction write
04
Observability Envelope
Prometheus + Loki + Tempo + Grafana
Metrics, logs, traces, and dashboards expose bottlenecks, failures, recovery signals, and system health.
logs / metrics / traces
05
Traffic Entry
Frontend + API
The buyer starts checkout in the frontend; the backend API receives the intent and passes it into the protected flow.
checkout intent boundary
Thesis Demo Proof
The architecture should prove four things.
The page should help reviewers explain why the system uses Redis, RabbitMQ, PostgreSQL, and centralized observability together.
Stock correctness
Oversell target: 0
Redis is responsible for the fast stock decision before valid checkout work continues.
Write stability
Queue before persistence
RabbitMQ separates checkout acceptance from final PostgreSQL writes.
Operational visibility
Logs, metrics, traces
LGTP makes the asynchronous flow explainable during a demo or incident review.
Load-test evidence
K6 validates pressure
The thesis story is completed by throughput, latency, and stock-correctness evidence.