The Order Timeout Question That Fails Most Backend Interviews
System design interviews increasingly filter on reliability thinking, not feature completion. A candidate who only describes the happy path signals they have never operated a service where tasks get lost, duplicated, or backlogged under load.
The naive answer—a cron job scanning the orders table every minute—collapses under millions of rows, introduces unacceptable timing jitter, and loses tasks when the scheduler crashes. The core shift is from polling the database to letting expired orders surface themselves through a delay queue. Redis ZSets store order IDs scored by expiration timestamp, shifting query pressure off MySQL and processing only the small slice of actually-expired records. The real differentiator is handling failure: atomically moving tasks into a processing queue via Lua scripts, deleting only after successful execution, and making every cancellation idempotent with conditional SQL updates. At tens of millions of orders, shard the ZSets by order ID hash; beyond that, evaluate MQ delayed messages or persistent queues with time wheels. A low-frequency fallback scan still runs to guarantee eventual consistency when everything else fails.
Most candidates fail this question not because they lack the technical knowledge, but because they answer the surface problem instead of the system-design problem the interviewer is actually probing.
The jump from 'it works' to 'it works when things break' is what separates a mid-level engineer from a senior one in backend interviews, and this question exposes that gap in minutes.
Redis ZSet is the answer that lets a candidate demonstrate breadth—data structure choice, atomicity, failure recovery, and sharding—all within a single coherent design.
The two-phase processing pattern with a separate processing queue is a general-purpose reliability technique that applies far beyond order cancellation, yet few candidates volunteer it unprompted.