A flash sale backend that stays safe when traffic peaks.
Go FlashArch is an e-commerce frontend built to demonstrate a thesis on high-performance backend architecture for flash sale systems through Redis, RabbitMQ, PostgreSQL, and centralized observability.
Thesis Title
Perancangan Arsitektur Backend High-Performance pada Sistem Flash Sale
Author
Muhamad Zidan Indratama
NPM
50422968
Program
Informatics
University
Universitas Gunadarma
Core focus: prevent over-selling and keep the database stable during concurrent checkout pressure.
Flash sales do not fail because the interface is slow. They fail when the backend loses control.
Database overload
Concurrent checkout can push too much write pressure into PostgreSQL in a short time window.
Latency spikes
Uncontrolled request queues increase response time and make checkout behavior unstable.
Over-selling
Non-atomic stock validation can allow more successful orders than the actual available stock.
Two research questions answered by this architecture.
Question 01
How can a backend architecture using Redis and RabbitMQ process high concurrent checkout requests without overloading PostgreSQL and without over-selling?
Question 02
How can centralized observability using Loki, Grafana, Tempo, and Prometheus help trace bottlenecks, failures, and recovery signals in an asynchronous system?
Frontend
The buyer sends checkout intent from the catalog or flash sale flow.
Redis
Stock validation and decrement are handled atomically.
RabbitMQ
Valid checkout work enters a queue so write pressure stays controlled.
Worker
Workers process queued messages and write the final state.
PostgreSQL
Orders and transactions become the durable source of truth.
LGTP
Logs, metrics, traces, and dashboards expose system health signals.
Frontend proof target: reviewers can see the request path, why Redis and RabbitMQ are used, queue state, checkout traces, and K6 results that explain latency, throughput, and over-selling count.
Thesis proof lives under About.
Architecture, observability, and load testing are grouped here so the main navigation stays focused on shopping flow while reviewers still get the full technical story.
Architecture
Request path and stock safety
Follow checkout from frontend intent to Redis, RabbitMQ, workers, PostgreSQL, and LGTP signals.
Open pageObservability
Metrics, logs, traces, health
Inspect queue depth, service status, log events, and trace timing in one thesis-ready ops view.
Open pageLoad Test
K6 pressure evidence
Run and explain throughput, latency, failure rate, and oversell correctness under flash sale load.
Open pageThis frontend is not a thesis poster. It is a product demo that explains the research contribution.
Landing page, catalog, flash sale, admin, observability, and load test screens should reinforce one story: the system stays measurable when checkout pressure rises.
Demonstrates the normal e-commerce flow before entering the flash sale scenario.
Separates fast stock reservation in Redis from final persistence in PostgreSQL.
Shows RabbitMQ as the pressure buffer for valid checkout work.
Makes observability visible as a product feature, not only a backend detail.
Provides a thesis-demo narrative that can be explained without extra context.