High-throughput serverless stream processing
stream design at scale.
partition by key for per-user ordering, use a sharded log with batched consumers for backpressure, and tune batch size and shards for cost.
a global FIFO queue or per-event invocation at 100k/sec.
What's really being asked
This assesses whether you can design a serverless pipeline that handles extreme throughput while preserving per-entity ordering and staying cost-effective, balancing three competing constraints.
The full answer
Use a partitioned, durable log stream such as Kinesis or Kafka rather than a plain queue. Choose the partition key as the user ID so every event for a given user hashes to the same shard; within a shard order is preserved, giving per-user ordering without the bottleneck of global ordering. Consumers read in batches; the log itself buffers events, so backpressure is handled naturally because consumers pull at their sustainable rate and the log retains data until processed. Scale by adding shards, and use a parallelization factor to run multiple concurrent processors per shard only where ordering allows. Control cost by processing in batches instead of one invocation per event, tuning batch size and window to amortize invocation overhead, and right-sizing shard count to the throughput. Send poison records to a DLQ and checkpoint progress so failures resume without reprocessing everything.
The mistakes people make
Proposing a single global FIFO queue, which serializes everything and cannot reach 100,000 per second. Invoking a function per individual event, which is slow and costly. Trying to guarantee total global ordering when only per-user ordering is required. Ignoring checkpointing, so any failure replays the entire stream. Forgetting backpressure entirely and overwhelming downstream stores.
What usually comes next
Why partition by user ID specifically? How does batching cut cost? What happens with a hot shard? How do you handle a poison record without blocking its shard?
A concrete example
Events are written to a 100-shard Kinesis stream keyed by user ID. A consumer reads batches of 500 records per shard, preserving order per user; failed records go to a DLQ and the checkpoint advances past them. Throughput scales with the number of shards while batching keeps the per-event invocation cost low, meeting the 100,000 per second target affordably.
Interview question
To keep all events for a given user ordered in a high-throughput stream while still scaling, what is the right approach?
- a.Use one global FIFO queue for strict total ordering
- b.Invoke a separate function per event with no batching
- c.Disable checkpointing to process faster
- d.Partition the stream by user ID so each user's events stay on one ordered shardCorrect
Why? this is the answer
Partitioning by user ID keeps each user's events on one shard where order is preserved, while many shards scale throughput. A global FIFO serializes everything and cannot scale; per-event invocation and no checkpointing hurt cost and reliability.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
- #serverless
- #streaming
- #kinesis
- #ordering
- #scalability
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on serverless — each one lists the topics its interview covers.
See open roles