FlashGrid - High-Concurrency Flash Sale Engine

FlashGrid is a stress-tested ticket reservation system designed to handle extreme bursts of traffic during flash sales. It utilizes an event-driven microservices architecture to sustain high throughput while guaranteeing strict data consistency (zero overselling).

The system decouples high-velocity ingress traffic from database write operations using a message queue, allowing it to process over 2,600 requests per second with sub-500ms latency on the client side.

System Architecture

The architecture follows the Producer-Consumer pattern to manage load leveling.

graph TD
    User["Clients / Stress Test"] -->|HTTP POST /reserve| Gateway["API Gateway (NestJS)"]
    
    subgraph "Ingestion Layer"
        Gateway -->|"1. Check Cache"| Redis["Redis Cluster"]
        Gateway -->|"2. Publish Event"| RMQ["RabbitMQ (Reservations Queue)"]
    end
    
    subgraph "Processing Layer"
        RMQ -->|"3. Consume Message"| Worker["Worker Service (NestJS)"]
        Worker -->|"4. Atomic Stock Check (Lua)"| Redis
        Worker -->|"5. Persist Transaction"| DB[("PostgreSQL")]
    end
    
    subgraph "Real-Time Feedback"
        Worker -.->|"6. Pub/Sub Update"| Gateway
        Gateway -.->|"7. WebSocket Emit"| Dashboard["Admin Dashboard (Next.js)"]
    end

Loading

Key Engineering Decisions

1. Queue-Based Load Leveling: Direct database writes cannot scale to meet flash sale spikes. FlashGrid accepts requests immediately at the API Gateway, validates them lightly, and pushes them to RabbitMQ. This acts as a buffer, protecting the database from the "Thundering Herd" problem.
2. Optimistic Locking via Redis Lua Scripts: To prevent race conditions (Double Booking) without slow database locks, the inventory decrement logic is executed inside a Redis Lua script. This ensures the "check-and-update" operation is atomic.

• Impact: Reduced database write load by 99.8% (only successful transactions hit the DB).

3. Real-Time Observability: The system pushes state changes via Redis Pub/Sub to the API Gateway, which broadcasts updates to the admin dashboard via WebSockets. This allows administrators to monitor Throughput (RPS) and Inventory Depletion in real-time without polling.

Tech Stack

Backend & Infrastructure

• Framework: NestJS (Node.js)
• Message Broker: RabbitMQ
• Caching & Locking: Redis (Lua Scripting)
• Database: PostgreSQL
• ORM: Prisma
• Containerization: Docker & Docker Compose
• Architecture: Monorepo (Turbo/Nx)

Frontend & Visualization

• Framework: Next.js
• State Management: Zustand
• Visualization: Recharts
• Real-Time: Socket.io Client

Performance Metrics

The system was stress-tested using a custom simulation script generating 10,000 concurrent requests against a stock of 20 items.

• Peak Throughput: ~2,600 Requests Per Second (RPS)
• Latency: <50ms API response time (Queue acknowledgement)
• Consistency: 100% (Zero overbooking observed across multiple test runs)
• Efficiency: 99.8% of invalid requests were filtered at the Worker/Redis layer, never touching the PostgreSQL disk.

Installation & Setup

Prerequisites

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

1. Clone and Install

git clone https://github.com/yourusername/flashgrid.git
cd flashgrid
pnpm install

2. Start Infrastructure

Start the RabbitMQ, Redis, and PostgreSQL containers.

docker-compose up -d

3. Environment Configuration

Copy the example environment files and configure database credentials.

cp .env.example .env

4. Database Migration

Initialize the PostgreSQL schema.

pnpm prisma migrate dev

5. Run Services

You can run the microservices in parallel.

# Terminal 1: API Gateway
pnpm start:dev api-gateway

# Terminal 2: Worker Service
pnpm start:dev worker

# Terminal 3: Frontend Dashboard
pnpm start:dev frontend

Running the Stress Test simulation

FlashGrid includes a load generation tool to demonstrate resilience.

1. Open the Admin Dashboard at http://localhost:3000/dashboard/stimulation.
2. Open the Gateway logs to monitor traffic.
3. Click "Launch Attack" on the dashboard.

• This triggers 10,000 concurrent requests to the /reserve endpoint.

4. Observe the Traffic Surge graph spike and the Safe Transactions bar lock at the maximum inventory limit.