Brownfield System Design Interviews: How to Answer Migration and Legacy Questions

Atlantean — Sat, 01 Aug 2026 14:25:38 +0000

The Prompt That Filters Greenfield Preparation

Somewhere in the middle of many senior loops, the interviewer abandons the clean-slate prompt and reaches for a different weapon: "We have a ten-year-old monolith handling checkout. Walk me through moving payments to its own service — without downtime, and without losing a cent."

You can watch preparation styles diverge in real time on this question. Candidates trained exclusively on greenfield prompts do something revealing: they design the destination — a lovely payments service with an API, a queue, a database — and present it as the answer. The interviewer nods, then asks the only question that matters: "Okay. It's Tuesday. The monolith is serving production traffic. What do you do first?" And the silence that follows is the sound of an entire preparation strategy meeting its blind spot.

Migration prompts are the fastest-growing genre in design interviews for a simple reason: they're the most job-shaped question available. Almost nobody at an established company builds green fields; everybody, forever, is renovating an occupied building. This piece is the method for answering them — and because interview method and real method are unusually close here, it doubles as an actual migration playbook.

Why Companies Ask Migration Questions

Understanding the scoring intent sharpens the answers. Migration prompts test three things greenfield prompts structurally cannot:

Risk sequencing. A greenfield design is evaluated on its end state. A migration is evaluated on its worst intermediate state — the design question becomes "order the steps so that no step is catastrophic, every step is reversible, and value arrives before the end." That's a different cognitive skill, much closer to what senior engineers actually spend their judgment on.

Respect for the existing system. Legacy systems encode years of undocumented business rules, edge-case handling, and quiet load-bearing behavior. Candidates who sneer at the monolith fail a character test the interviewer may not even know they're running: the ten-year-old system works, serves the business, and contains knowledge; contempt for it predicts a specific and expensive style of real-world failure.

Comfort with constraint. Greenfield rewards imagination; brownfield rewards operating inside constraints you didn't choose — a fixed schema, a team that owns half the tables, a compliance freeze in December. Constraint-comfort is the temperamental core of staff-level work.

The Core Insight: You're Designing a Sequence, Not a System

The single reframe that separates passing answers: the deliverable is an ordered set of safe states, not an architecture diagram. The destination architecture is maybe 20% of the answer, sketched briskly. The other 80% is the path — where each intermediate state must satisfy three invariants:

Production keeps working at every state, under full traffic, during the transitions between states.
Every state is observable — you can tell, with data, whether the current step succeeded before taking the next.
Every state is retreatable — each step has a rollback that doesn't require heroics, until the explicitly-named point of no return, which you call out as such.

Say this reframe out loud, early: "The interesting design problem here is the sequence of safe states, so let me sketch the target briefly and spend our time on the path." That sentence alone relocates you into the top quartile of answers, because it demonstrates you've heard the actual question.

The Migration Method: Five Phases

The reusable skeleton, adaptable to nearly any migration prompt:

flowchart LR
    P1[1. Characterize<br/>the incumbent] --> P2[2. Carve the seam<br/>+ strangler facade]
    P2 --> P3[3. Shadow<br/>dual-run, compare]
    P3 --> P4[4. Shift<br/>incremental cutover]
    P4 --> P5[5. Settle<br/>decommission + guard]

Phase 1 — Characterize. Before touching anything: what does the incumbent actually do? Instrument it — call patterns, traffic shape, hidden consumers (the analytics job reading the database directly; there is always one), and the undocumented behaviors clients depend on. The interview version is one crisp minute: "First I'd spend real time learning what checkout actually depends on, because the monolith's documented interface and its true interface differ — direct DB readers, implicit ordering guarantees, side effects someone built a business process on." Interviewers reward this phase disproportionately; skipping it is the tell of someone who's never been burned.

Phase 2 — Carve the seam. Introduce an interception point without changing behavior: a facade/proxy through which all payment calls route, still delegating 100% to the monolith. This is the strangler-fig move, and its subtlety is worth stating: the facade ships to production doing nothing new — a zero-behavior-change deploy that creates the control point every later phase needs. Risk arrives in small, separately-shippable pieces.

Phase 3 — Shadow. The new service runs alongside, receiving mirrored traffic; results are compared, not served. Discrepancy dashboards become your correctness proof — and the discussion of what discrepancies you tolerate (timestamp jitter: yes; amount differences: never) shows judgment. Shadowing is where the undocumented behaviors from Phase 1 reveal themselves as diffs, cheaply, harming nobody.

Phase 4 — Shift. Cut over incrementally along whatever axis limits blast radius: percentage dials, tenant cohorts, low-risk payment types first. Each increment: shift, observe against defined success metrics, hold, proceed. Name your abort criteria before the first shift — "if discrepancy rate exceeds X or p99 regresses Y%, the dial goes back to zero" — because abort criteria defined during an incident are negotiations, not criteria.

Phase 5 — Settle. The forgotten phase, and mentioning it scores: decommission the old path actively (code deletion, connection revocation — an "off" monolith path that can be silently re-enabled is a haunted house), migrate the stragglers you found in Phase 1, and install guards against regression — the linter rule or architectural test that stops next quarter's engineer from calling the monolith's internals directly again.

The Data Question: Where Migration Interviews Are Decided

Service code migration is the easy half, and interviewers know it. The discriminating territory is state: the monolith's payments tables are entangled — foreign keys into orders and users, shared transactions, that analytics reader. Expect the probe: "how does the data move?"

The answer framework — sequence the coupling apart:

Logical separation first: stop new cross-domain foreign keys and joins now (cheap, immediate); route the monolith's own payment-data access through an internal interface, converting invisible coupling into visible, countable calls.
Dual-write with one source of truth: writes go to both stores, old store remains authoritative, new store's correctness is measured (row-level reconciliation jobs, not vibes) before anything reads from it. State plainly that dual-writes are a known lie without care — order the write so the authoritative store's failure aborts the operation, and let reconciliation catch the async drift.
Read migration by consumer, riskiest last: move readers to the new store one at a time, each independently rollback-able. The direct-DB analytics reader gets an explicit interim contract (a view, an export) — you don't break the CFO's dashboard to satisfy an architecture diagram.
Authority flip: the named point of no return, done during low traffic, with the reconciliation delta at zero for N days as the gate. After the flip, old-store writes continue briefly (reverse dual-write) as the retreat path, then stop.

Candidates who volunteer the reconciliation-job detail — measuring store agreement instead of assuming it — almost always turn out to have done a real migration, and interviewers treat it as exactly that kind of evidence.

Worked Example: Splitting Payments Out of a Monolith

Compressed to interview cadence, the full answer to the opening prompt:

"Target state, ninety seconds: payments service, own datastore, sync authorize API, events for downstream consumers — standard shape, and not the interesting part. The interesting part is the path, because checkout is live and money is involved.

Week one is archaeology, not code: traffic characterization and a dependency census on the payment tables. I expect to find direct readers and at least one behavioral quirk clients depend on — say, that authorization and order-state update happen in one transaction, which clients experience as read-your-write consistency. That transactional coupling is my hardest problem; flagging it now.

Then the seam: an in-process facade over payment logic, deployed with zero behavior change. Then out-of-process: the facade can route to a service that initially just proxies back. Each step is a boring deploy — that's the point; risk arrives in doses.

Shadow phase: mirror authorize calls, compare decisions and amounts, drive the discrepancy dashboard to a flat zero on amounts before anyone's money touches the new path. The transaction coupling gets resolved here — the new service can't join the monolith's transaction, so the order-state contract changes from transactional to read-your-write-via-token, and that becomes an explicit client-facing change I'd version and communicate, not sneak.

Cutover by payment type — gift cards before credit cards — with percentage dials inside each, abort criteria written down first. Data follows the dual-write/reconcile/flip sequence with the reconciliation delta gating the authority flip. Settle phase: delete the monolith's payment code, revoke its processor credentials — the strongest guarantee available that the old path is dead — and leave an architectural test that fails if anyone reintroduces a cross-domain join.

Total calendar honesty: this is quarters, not sprints, and the first user-visible benefit ships mid-path, not at the end — the shadow infrastructure alone gives us payment observability the monolith never had."

That answer runs about four minutes and touches every phase, names the hardest problem unprompted, and includes the two details (reconciliation gating, credential revocation) that read as scars rather than study.

The Rollback Conversation

Interviewers probe retreat paths on every migration answer, and there's a hierarchy of answer quality. Weak: "we'd roll back the deploy." Adequate: per-phase rollback mechanics — dials to zero, facade re-pointed, reverse dual-writes. Strong adds the two things practitioners know: rollback windows close (after the authority flip plus data divergence, retreat becomes a data-merge project, which is why the flip gate is so conservative), and rollback is a tested artifact — "we'd exercise the retreat path in staging per phase, because an unrehearsed rollback is a second incident." If you say only one sophisticated thing about rollback, make it the closing-window observation; it demonstrates you understand migrations as irreversibility gradients, not toggles.

Organizational Sequencing: The Staff-Level Layer

At staff calibration, a further probe arrives: "who does all this?" The system sequence has an organizational shadow — and strong answers address it unprompted. The payments split is also a team split: who owns the facade during transition (the seam is a shared artifact with two masters — name a single owner or it rots), how the monolith team's roadmap absorbs a multi-quarter tax for a benefit that mostly accrues to others (this is where migrations actually die — the incentive gap, not the technical gap), and what you ship early to keep sponsorship alive (the observability win, deliberately scheduled first, is political fuel as much as engineering value).

One sentence of this layer — "the riskiest dependency here isn't the data; it's that the monolith team has no incentive to fund quarters of this, so I'd sequence an early win that benefits them directly" — is among the highest-signal sentences available in this interview genre. The pattern-level thinking behind it, sequencing value to sustain multi-team efforts, is core Staff engineer interview preparation territory, and it transfers straight back to the job.

Common Mistakes

Designing the destination and calling it the answer. The question was the path; the target architecture is the cheap 20%.
Big-bang cutover framing. Any answer shaped like "then we switch over" — singular — has failed the reversibility invariant.
Contempt for the incumbent. "First we get rid of this mess" tells the interviewer how you'll talk about their systems.
Ignoring hidden consumers. No dependency census means the CFO dashboard breaks in your second week; interviewers who've lived this listen for the census specifically.
Dual-writes asserted rather than measured. Without reconciliation machinery, dual-write answers are the distributed-systems equivalent of "trust me."
A path with no early value. Multi-quarter sequences that deliver everything at the end fail both the interview probe and, in reality, the funding conversation their real versions face.

Best Practices

Open with the reframe — sequence of safe states, destination sketched briefly — and allocate time accordingly.
Walk the five phases by name: characterize, carve, shadow, shift, settle. The skeleton keeps you complete under pressure.
Treat data separation as the centerpiece: logical decoupling, measured dual-writes, per-consumer read migration, gated authority flip.
Name your point of no return explicitly, and describe how conservatively you'd gate it.
Volunteer abort criteria before describing any cutover dial.
Add the organizational layer unprompted at senior-plus loops: seam ownership, incentive gaps, early value for the taxed team.
In practice sessions, rehearse migration variants of every canonical greenfield problem — "design a feed" becomes "replace this feed without readers noticing."

Key Takeaways

Migration prompts test risk sequencing, respect for working systems, and constraint-comfort — dimensions greenfield prompts can't reach.
The deliverable is an ordered set of safe states, each working, observable, and retreatable; the target architecture is a brief sketch.
The five-phase skeleton — characterize, carve, shadow, shift, settle — adapts to nearly any migration question.
Data migration decides these interviews: dual-writes must be measured by reconciliation, and the authority flip is a named, conservatively-gated point of no return.
At staff level, add the organizational shadow: seam ownership, incentive gaps, and early value sequenced to sustain sponsorship.

FAQ

How much time should the target architecture get in a 45-minute migration answer?
Five minutes or less. If you're still describing the destination at minute fifteen, you're answering the greenfield question the interviewer deliberately didn't ask.

What if the interviewer's prompt is greenfield but the company is famously brownfield?
Answer the prompt as given, but plant one hook: "and if this were replacing an existing system, the cutover sequence would be its own design problem." They'll either take the thread — many will, gratefully — or you've lost nothing.

Is the strangler-fig pattern always the right frame?
It's the right default for live systems; say so, then note the exceptions — tiny blast radius, tolerable downtime windows, or systems being retired rather than replaced, where a freeze-and-cutover can honestly be cheaper than months of dual-running.

How do I practice this without having done a major migration?
Take any system you know and design its replacement path under the three invariants. Also mine public engineering blogs: large-scale migration write-ups (database swaps, monolith splits, cloud moves) are abundant, and re-deriving their sequencing decisions before reading their reasoning is superb calibration.

Do zero-downtime requirements ever get relaxed in these interviews?
Ask! "Is a maintenance window on the table, and what's it worth?" is a scoring question — it prices a constraint instead of accepting it silently, and occasionally the interviewer's scenario has a window hidden behind exactly that question.

Conclusion

Greenfield questions ask whether you can imagine a good system. Migration questions ask whether you can get there from here — with traffic flowing, money moving, teams mid-roadmap, and no step allowed to be the catastrophic one. It's a harder question and a truer one; the second kind is nearly all of what senior engineering actually is.

The encouraging corollary: because the method is the job, practicing it compounds. Learn to characterize before carving, to shadow before shifting, to gate the irreversible step behind measured agreement, and to sequence early value for the people paying the tax — and you've prepared simultaneously for the interview's hardest genre and for the Tuesday, some quarters from now, when the building you're renovating is occupied and real.

DEV Community: Atlantean