Section 9: Break It If You Can - Interviewer Deep-Dive Challenges

Executive Summary: With the rollout loop and the byte path on the board, the interviewer starts asking how it fails. Seven escalations follow, each answered by a decision already made, with its number and the point where it flips.

The pattern for every one: don't redesign. Name the mechanism, give its number, say what would flip it.

Challenge 1: The Release Changes a Database Column

"Suppose r-1432 also renamed a column. What happens?"

What they're really asking: Do you know that a rolling deploy means two versions run at once, against one database?

The model answer: For up to about 3.2 hours, N and N-1 serve side by side on the same tables. A rollback widens that window: when Sam's r-1432 was rolled back at 16:48, zone A1 had run it for over an hour and all of region A for half an hour, and r-1101 would then have to read every row r-1432 wrote. So no release may write anything its predecessor can't read. A rename becomes three releases:

The drop is a separate schema step that runs only once Release 2, which still writes the old column, is no longer a rollback target. Each release finishes its rollout before the next starts, so every adjacent pair is compatible both ways.

Interviewer: "That's three deploys for a rename."

You: "Three trains instead of one, yes. The alternative is a rollback that corrupts data, and then rollback stops being the cheap button the whole design relies on."

The senior line: "A rolling deploy is a version-skew window. Schema changes go expand, migrate, contract, so N-1 can always read what N wrote."