FlashFlow ⚡

High-Concurrency Flash Sale & Settlement Engine

FlashFlow is a backend engine designed to handle extreme traffic spikes typical of flash sales (e.g., Ticketmaster, Zomato, Flipkart). It solves the classic "Race Condition" problem in inventory management and ensures 100% transactional reliability using an event-driven architecture.

---

🚀 Key Results (Stress Test)

Benchmarked using Autocannon with 100 concurrent connections for 5 seconds:

Metric	Result	Context
Throughput	17,772 req/sec	~35x faster than standard SQL updates
Latency	5.15 ms	Sub-10ms response time under load
Reliability	100%	Zero overselling (Sold exactly 100/100 items)
Traffic	89,000 requests	Handled in 5 seconds without crashing

Verification: The system successfully rejected 88,752 requests with "Sold Out" while processing exactly 100 valid orders.

---

🏗️ System Architecture

The system uses a microservices-style approach to decouple high-speed ingestion from reliable data persistence.

Client -> API Gateway (Node.js) -> Redis (Atomic Lock) -> RabbitMQ -> Worker Service -> PostgreSQL

1. The "Zomato" Module (Ingestion & Locking)

• Problem: Standard "Read-Modify-Write" database operations cause race conditions when thousands of users buy the last item simultaneously.
• Solution: Implemented Redis Lua Scripting. Redis executes the script atomically (single-threaded), effectively creating a "memory lock" that prevents overselling.
• Tech: Node.js, Redis, Lua.

2. The "Visa" Module (Reliability & Settlement)

• Problem: Writing every order directly to a SQL database during a spike will crash the database (Connection Pool exhaustion).
• Solution: Used RabbitMQ to buffer successful orders. The API responds immediately ("Order Placed"), while a background Worker Service drains the queue at a safe pace and ensures ACID-compliant storage in PostgreSQL.
• Tech: RabbitMQ, PostgreSQL, Docker.

---

🛠️ Tech Stack

• Runtime: Node.js (Express)
• Database: PostgreSQL 15 (Dockerized)
• Cache/Locking: Redis 7 (Dockerized)
• Message Broker: RabbitMQ 3 (Dockerized)
• Infrastructure: Docker Compose
• Testing: Autocannon (Load Testing), Postman

---

🏃‍♂️ How to Run Locally

Prerequisites

• Docker & Docker Compose
• Node.js (v18+)

1. Start Infrastructure

Spin up Redis, PostgreSQL, and RabbitMQ containers.

docker-compose up -d

2. Install Dependencies

npm install

3. Initialize Database

Run the setup script to create the necessary tables in Postgres.

node setup-db.js

4. Start the Microservices

Terminal 1 (API Server):

node index.js

Terminal 2 (Worker Service):

node worker.js

5. Run a Load Test

Reset the stock to 100 and simulate a traffic spike.

Initialize 100 items

curl -X POST http://localhost:3000/init

Attack with 100 concurrent users for 5 seconds

npx autocannon -c 100 -d 5 -m POST http://localhost:3000/buy

📸 Screenshots

1. Load Test Results (17k req/sec)

2. Database Verification (Exactly 101 Rows) i have added an 1 extra user before running the test and then did the test to buy iphones for 100 users , so technically 101 Rows is correct(100 + 1extra i added before the autocanon test)