Upgrading a stateful Flink job without losing state

WHAT THIS TESTS The interviewer wants to see that you know Flink's savepoint mechanism, the role of operator UIDs in state mapping, and the difference between checkpoints and savepoints for planned upgrades.

A GOOD ANSWER COVERS The upgrade sequence. First trigger a savepoint, a complete consistent snapshot of every operator's keyed and operator state plus source offsets, written to durable storage and owned by you rather than by the runtime. Stop the running job; use stop-with-savepoint, and optionally drain to flush event-time windows if you intend to fully finish. Deploy the new application jar with the updated session logic. Start the new job with the resume-from-savepoint flag so each operator reloads its prior state and processing continues from the saved offsets without reprocessing or losing in-progress sessions.

WHY OPERATOR UIDS MATTER Flink maps saved state back to operators by their UID. If you do not set explicit, stable UIDs, an autogenerated UID can change when the job graph changes, and Flink will fail to find or silently allow dropping that state, losing all in-flight session windows. So assign UIDs to every stateful operator and keep them constant across versions, and keep state serialization schema-compatible.

CHECKPOINTS VS SAVEPOINTS Checkpoints are for automatic failure recovery and may be cleaned up; savepoints are explicit, durable, and the supported tool for upgrades and migrations.

LIKELY FOLLOW-UPS How to handle incompatible state schema changes, what allowNonRestoredState does, and how to migrate state backends.

ONE CONCRETE EXAMPLE To ship new session-gap logic you run stop-with-savepoint, get a savepoint path, submit the new jar with that path as the restore point, and because every operator kept its UID, the open 30-minute sessions resume exactly where they paused.