A service processing events from message queues like Kafka and Redis Streams initially spawned a Tokio task for each user token within an event, leading to approximately 1 million tasks during a burst. The expectation was that earlier tasks would complete first, but logs revealed that tasks from earlier events were being polled much later.

Tokio's multi-threaded runtime, with its local and global queues, mixes tasks. When many tasks are submitted concurrently, Tokio prioritizes making progress over strict ordering. Tasks from different events compete for worker queues, and scheduling mechanisms like queue overflow and work stealing can alter the polling order. This meant some early tasks remained live longer, increasing peak memory usage.

The article emphasizes that "spawned early doesn't mean first-polled early." The application needs to provide bounds for fairness. By introducing a Semaphore to limit the number of concurrently processed events, the service achieved event-level fairness, significantly reducing peak memory while still meeting throughput requirements. This highlights that Tokio handles tasks fairly but doesn't inherently understand application-level units of work like events.