Interactive Traffic Sandbox

01 /Words You Need

• Topology: The arrangement of nodes and network edges showing how requests flow from clients to storage.
• Pipeline Validation: Rules preventing illegal network connections, such as connecting a client directly to an internal database without an application server or load balancer.
• Mean latency: The steady-state sojourn on this canvas. Utilization is clamped at 0.9, then time is base milliseconds divided by (1 minus that utilization). It is not a Poisson simulation and it does not draw random arrivals.
• Model tail: The mean multiplied by a factor of how full the busiest box is. If any request failed, the number is at least 500 ms. A real M/M/1 sojourn is exponential, so a true p99 is about 4.6 times the mean. This widget does not compute that. There is no token bucket here. Caps, queues, and the circuit breaker are the limits. Token buckets are in the email gateway lesson and the rate-limiter note.
• Connection Pool Exhaustion: A failure mode where all database worker connections are locked by slow queries, starving healthy requests and causing timeouts.
• Queue buffering: A queue accepts jobs up to its cap and hands them to workers at the rate they can write. Jobs that fit in 15 seconds of buffer wait. Jobs above the cap, or above that buffer, are rejected. A real Kafka log can wait longer, until the disk fills.

02 /In Plain Words: The Wedding Buffet Analogy

Imagine a large Indian wedding feast with 5,000 guests arriving at once.

If all 5,000 guests rush directly into the kitchen to grab food from the chef's pans (Client connecting directly to Database), the kitchen collapses. Cooks drop ladles, vessels tip over, and nobody eats.

To survive, you organize the feast into stages:

1. Security gate and ushers (Load Balancers) direct guests evenly across multiple dining halls.
2. Buffet counters (App Servers) serve ready items quickly.
3. Chafing dishes on the counter (Caches) hold 90 percent of the food so guests do not ask the kitchen for every single puri.
4. Kitchen order tokens (Queues and Workers) take orders for hot jalebis and prepare them at a steady rate.
5. Main kitchen stoves (Databases) remain protected from the crowd, running smoothly at steady capacity.

A buffet does not fail 90 percent of guests when the kitchen is slow. A database does, because the connection pool is finite. The analogy shows the layers. The canvas shows the drops.

This sandbox lets you assemble those exact layers. When you skip a layer, dialling traffic up will show you the exact component that catches fire.

03 /How to Build and Test Your Architecture

1. Component Palette and Placement

Use the palette at the top of the canvas to drop components:

• Client: Generates incoming simulated HTTP traffic.
• Load Balancer: Distributes requests across downstream application servers.
• App Server: Executes application logic, enforces rate limits, and routes to storage or queues.
• Cache: Resolves read requests with low latency (default 85 percent to 95 percent hit ratio).
• Queue: Accepts jobs up to its cap and lets workers drain them. The overflow waits up to 15 seconds of buffer, then it is rejected.
• Worker: Consumes jobs from queues and performs background processing.
• Database: Persistent storage sink with connection pool limits and base query latency.

2. Wiring Rules (Pipeline Validation)

To connect two components, click a component in the canvas and press Connect to..., then click the target component. The engine enforces production-safe network boundaries:

• Client can only connect to a Load Balancer or an App Server.
• Load Balancers can only route to App Servers.
• App Servers can route to Caches, Databases, or Queues.
• Queues can only feed Workers.
• Workers write to Databases.
• Databases cannot route backwards. The type rules reject a back edge. A cycle check also runs, for a graph the type rules would otherwise allow.

3. Tuning Component Parameters

Click any component to open the Inspector Panel:

• Capacity: Adjust maximum throughput from 500 to 50,000 requests/second.
• Base Latency: Adjust processing delay from 1 to 100 milliseconds.
• Hit Ratio (Cache): Tune read hit percentage from 50 percent to 99 percent. This changes how much traffic reaches the database.
• Max Connections (Database): Set the pool from 10 to 200 connections. Throughput is the lower of the capacity slider and connections / query seconds. 50 connections at 25 ms allow 2,000 requests a second.
• Stop / Start: Simulate hard machine crashes and failover recovery.
• Delete Component: Remove bottlenecks and re-wire alternatives.

04 /Three Built-in Architecture Presets

Use the Preset buttons on the top bar to inspect realistic Indian scale challenges:

1. IRCTC Tatkal at 10:00 AM (50,000 req/s)

• What you see: Four application servers handle all 50,000 incoming requests, but they slam a single PostgreSQL database with capacity 5,000/s.
• The bottleneck: 45,000 requests per second fail immediately (90 percent failure rate). The database turns red at 1,000 percent utilization.
• How to fix it: Lower the load or insert an asynchronous queue and background workers between the app servers and the database to buffer ticket reservations.

2. Twitter URL Shortener (20,000 req/s)

• What you see: Two app servers route reads to a Redis cache with a 95 percent hit ratio.
• The balance: 19,000 requests per second resolve in 2 ms directly from cache. Only 1,000 requests per second reach the database (cap 3,000/s). All 20,000 requests succeed with zero errors.
• Break it: Click the Redis cache and press Stop component. Watch what happens when cache drops to 0: all 20,000 requests slam the database directly, causing 17,000 requests per second to drop with timeouts.

3. Flipkart Big Billion Days Flash Sale (10,000 req/s)

• What you see: An API Gateway receives 10,000 orders per second on a single discounted smartphone SKU.
• The protection: The Order API accepts all 10,000 orders into the queue. Three workers write 2,500 each, so 7,500 orders a second reach the database and 2,500 a second wait. Nothing is rejected at this rate. The wait is the cost.

05 /Challenge Mode

Switch to the Challenges tab in the top bar to test your architecture against 3 puzzles:

1. Challenge 1: IRCTC Tatkal Surge
   • Keep the system alive at 20,000 requests/s with p99 latency under 200 ms and zero errors.
   • Illustrative budget under ₹50,000 a month. The price is a flat stipend per box. Moving a capacity slider does not change it. It is not an AWS bill.
2. Challenge 2: Survive Cache Death
   • Run 10,000 requests/s on the URL shortener.
   • Stop the cache component. Your architecture must keep success above 99 percent and prevent the database from exceeding 100 percent capacity.
3. Challenge 3: Absorb a 5x Flash Spike
   • Hit the flash sale architecture with 30,000 orders a second.
   • Fewer than 1 percent may be rejected. A live database must still be draining the queue. Orders may wait.

Solving each challenge unlocks an instant verification badge and links directly to the real Docker lab.

06 /In Real Projects: What Simulations Hide

Interactive canvas simulations teach you structural flow, bottleneck identification, and capacity boundaries. But production environments carry physical nuances that no single-page browser model can simulate:

1. TCP Connection Leaks: In real Node.js or Java backends, unclosed database connection objects do not reset gracefully. They leak file descriptors until the OS refuses ECONNREFUSED.
2. Noisy Neighbours and VM Steal: Cloud virtual machines share hypervisor CPU cores. Background compaction jobs on nearby instances can steal 20 percent of your CPU cycles during peak hours.
3. Garbage Collection Pauses: A JVM or Go runtime experiencing heap pressure can freeze threads for 400 ms, causing upstream load balancers to trip health checks even when the process is technically alive.
4. Cold Starts and Connection Surges: When auto-scaling spawns 20 new app servers during a flash sale, 20 new connection pools slam PostgreSQL simultaneously, knocking it offline before any customer request is served.

That is why our methodology pairs theoretical simulation with hands-on container verification.

07 /Run It for Real in Docker

Once you have assembled your architecture in this canvas, run the real infrastructure in our hands-on Docker labs:

• Database Connection Pool Exhaustion: Run real PostgreSQL 16 containers with Toxiproxy and PgBouncer under 1,000 concurrent client threads.
• Redis Cache-Aside and Stampede: Run real Redis 7 cluster containers with key expiry and test single-flight mutex coalescing under live traffic.
• Kafka Consumer Groups and Lag: Spin up Apache Kafka 3.8 and test consumer group partition rebalancing and lag buildup under 5,000 messages per second.