Consider a fraud detection system that consumes transaction events, keeps per-user velocity counters, joins recent behavior with rule updates, and emits a decision fast enough to affect authorization.

Or perhaps you are designing a real-time analytics dashboard that must aggregate click streams across thousands of dimensions while handling data that arrives out of order due to network delays.

These problems share a common challenge: processing unbounded streams with low latency while keeping state correct across retries, late events, and worker failures.

This is where Apache Flink is usually considered.

Flink is a distributed engine for stateful computation over bounded and unbounded streams. Its interview value comes from three ideas: state, event time, and checkpoints.

State lets a job remember per-user, per-device, or per-session facts. Event time and watermarks let it compute windows based on when events happened, not when they arrived. Checkpoints let Flink recover operator state consistently after failures. End-to-end exactly-once output is possible only when the source can replay and the sink is transactional or idempotent.

This chapter focuses on the interview-level mechanics: when to choose Flink, how state and watermarks affect correctness, how checkpointing works, and what operational risks to call out.

The diagram shows how a Flink job moves from the client through the JobManager to TaskManagers, where the work runs as a dataflow that reads from sources, processes records in task slots, and writes to sinks.