Apache Flink
maang.io System Design Series
Apache Flink processes streams a record at a time (not micro-batches), with first-class support for the hard parts of streaming: event time vs processing time, watermarks for out-of-order data, windowing, and large managed state. Its exactly-once guarantee comes from asynchronous barrier snapshots (the Chandy-Lamport algorithm). It's the go-to for stateful, low-latency stream processing.
This deep dive comes in three parts:
- Foundations & Core Concepts — streams, event time, and watermarks.
- Internals — windowing, keyed state (RocksDB backend), and checkpointing/exactly-once, with worked numbers.
- Interview — Staff/Principal Q&A: event-time reasoning and Flink vs Storm vs Spark.
Apache Flink — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know Flink from the dataflow graph down to barrier alignment. This chapter is where that pays off in a system-design loop. An interviewer doesn't want to hear "Flink does exactly-once" — they want to watch you reach for stream processing at the right moment, place it correctly in an architecture, and defend the event-time and consistency trade-offs when they push. That judgment is the senior signal.
Two things here: first, where Flink fits in real designs (with diagrams), then a mock interview — for each question, what they're really asking, a model answer, and the senior line that says you've shipped this for real. We'll keep the sorting office in the back pocket the whole way.
The one-line idea: interviewers use Flink to test whether you can tell streaming-shaped problems (continuous, stateful, event-time, correctness-critical) from batch or request/response ones — and then reason honestly about the costs: watermark latency, state size, checkpointing overhead, and the operational weight of a stateful cluster.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson