Apache Storm
maang.io System Design Series
Apache Storm pioneered real-time stream processing: you build a topology — a DAG of spouts (sources) and bolts (processing) — and tuples flow through it. Its clever acker tracks each tuple's tree with XOR checksums to guarantee at-least-once processing. Studying Storm shows why later systems like Flink adopted event time and exactly-once, and where Storm still fits.
This deep dive comes in three parts:
- Foundations & Core Concepts — topologies, spouts/bolts, and stream groupings.
- Internals — tuple-tree acking, Nimbus/supervisors/workers, and Trident, with worked examples.
- Interview — Staff/Principal Q&A: reliability semantics and Storm vs Flink/Spark.
Apache Storm — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know Storm from the topology down to the XOR checksum. This chapter turns that into interview signal. An interviewer doesn't want you to recite "Storm uses an acker" — they want to watch you reach for stream processing at the right moment, reason about the delivery guarantee, and defend the trade-offs when they push, especially the one everyone asks now: "Storm is kind of old — why, and what would you use instead?" Handling that gracefully is a stronger signal than any internal detail.
We'll do two things: see where a Storm-style processor fits in real designs (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've built this for real.
The one-line idea: interviewers use Storm to test whether you understand streaming's core tensions — latency vs correctness, at-least-once vs exactly-once, tuple-at-a-time vs micro-batch — and whether you can place a real-time layer in a system and live honestly with its guarantee.
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