How real-time systems handle 100K cancel requests per second

Imagine pressing "Cancel Order" on your favorite two-minute noodles app, only to find the driver has already rung your doorbell. The button disappears the moment reality changes—not when your app refreshes. For services operating at hyper-scale, this isn’t just a UX nicety—it’s a critical race against physics.

That’s the challenge Flipkart Minutes faced when millions of users expected an order cancellation button to vanish instantly the second a delivery person arrived. At peak load, the system had to process over 100,000 requests every second—all while maintaining real-time accuracy. The solution wasn’t built on bigger servers, but on smarter logic. Here’s how it works.

The Hidden Traffic Avalanche Behind Every Order

Behind the scenes of a fast-delivery app lies a storm of silent requests. Users aren’t just ordering—they’re watching. The Map Viewers, who stay glued to the live delivery tracker, trigger a UI refresh every 30 seconds. Over a 15-minute delivery window, that’s up to 30 background hits per user. Meanwhile, Chat Viewers open support threads expecting instant updates. Each opens a single eligibility check on page load—but if the driver arrives mid-conversation, the system must react without a refresh.

When scaled across tens of thousands of concurrent users, these behaviors generate a relentless flood: 100,000+ requests per second (RPS) bombarding the backend. The cancellation button isn’t just a button—it’s a moving target that must disappear the instant the driver steps onto the porch.

The Three Rules of a Real-Time Cancellation System

Three systems share responsibility for the "Cancel Order" button:

• UI Layer: Renders the button on the customer’s screen
• Eligibility Service: Decides whether the button should appear right now
• Fulfillment System: Tracks driver location and order status

Three hard rules govern its behavior:

• Show the button only if more than 10 minutes have passed since order placement.
• Hide it immediately when the driver’s status changes to "Arrived at Doorstep".
• Never, ever crash under 100,000 RPS.

Violating any rule risks free ice cream—or worse, a frozen server.

Why Naive Solutions Fail Under Load

The first instinct is simple: every time a user loads the map, ask the Eligibility Service, which checks Fulfillment for the latest status. But this "Chain Reaction" approach treats Fulfillment like a read-heavy database. In reality, it’s a live GPS engine managing thousands of moving drivers. Pinging it 100,000 times per second clogs its pipeline, locks databases, and brings the entire app to its knees.

A smarter attempt uses background workers to poll order statuses and cache results. But this "Are We There Yet?" loop is wasteful—over 95% of the time, the answer never changes. Constant polling burns CPU cycles, drains energy, and introduces a 2-second delay. That’s long enough for a user to exploit the gap, click Cancel, and walk away with free food.

The Lazy Genius: Do Nothing, React When Needed

The winning strategy flips the script: stop chasing time, let time chase you. Instead of asking "Is it time to hide the button?" every 30 seconds, the system calculates the answer once—at order creation.

When a user places an order at 8:00 PM, the Eligibility Service stores a single timestamp in Redis:

Cancellation_Allowed_After: 8:10 PM

Every time the UI refreshes, the service performs a sub-millisecond lookup and runs a lightning-fast check:

const passed_sla = current_time > promised_delivery_timestamp;
const is_at_doorstep = (driver_status === "ARRIVED_AT_DOORSTEP");

if (passed_sla && !is_at_doorstep) {
  return show_cancel_button = true;
} else {
  return show_cancel_button = false;
}

No background loops. No repeated polls. No database strain. The clock does the work.

For the support chat page needing true real-time accuracy, a different trick takes over. When Fulfillment detects a driver arrival, it broadcasts an event via Apache Kafka: "Order 123: Driver Arrived!". The Eligibility Service listens, flips the status in Redis, and pushes an instant WebSocket message to the user’s chat window. The button vanishes before the user’s finger lifts from the screen.

Scale Without Sacrifice: The Engineering Lesson

Scaling isn’t about raw horsepower—it’s about eliminating unnecessary effort. The Flipkart Minutes team learned this the hard way: active timers waste cycles, repeated polls waste bandwidth, and live queries waste lives.

The future of real-time systems lies in event-driven laziness: calculate once, react once. Whether it’s canceling an ice cream order or routing a city’s traffic, the smartest systems do less work, not more.

As user expectations rise and delivery windows shrink, the lesson is clear: the best engineering isn’t the fastest—it’s the most efficient.