skip to content

Two years on, your store has grown so large in its region that the placement looks irreversible — how do you decide whether to move it?

level: principalimportance: nice to knowfreq 30%

answer

  1. one-time cost against recurring harm
  2. attachments, not just bytes
  3. the bytes are charged leaving
  4. compliance makes it mandatory, economics compare
  5. price the cheaper alternatives first

basics

~20 s

Weigh the one-time cost of moving — bytes charged on the way out, engineering time, a cutover window and its risk — against the recurring harm of staying. Then consider the cheaper answers: move only the latency-sensitive path, or place new growth differently and leave the existing store alone.

solid answer

~50 s

Make it a comparison, not a feeling. On one side put the **one-time cost**: the bytes are charged leaving the region, everything attached to the store has to cut over consistently, and you need either a window or a replicate-then-switch plan with a verified rollback. On the other put the **recurring harm**: the latency floor your users pay, a rate gap you keep paying, or an obligation you are now out of compliance with. Only a compliance driver makes the move mandatory; the others are economics, and economics compare. Before committing, cost the two cheaper answers honestly — moving just the latency-sensitive read path closer to users, or directing new growth to a better-placed region while the existing store stays. And write down what you would do differently: keep the region a parameter rather than a constant, so the next placement is a decision and not an inheritance.

go deeper

for a junior

Know that moving a large store between regions is expensive rather than impossible, and that the expense comes from the charge on the way out plus everything connected to it having to move too.

for a middle

Be able to list both sides: the one-time transfer, engineering, cutover and risk against the recurring latency, rate and compliance harm, and explain why traffic is charged outbound.

for a senior

Show the migration you would actually run — replicate, verify at the destination, cut over with a tested rollback, decommission last — and name the attachments that make it larger than the byte count suggests.

for a principal

Own the call itself: separate a mandatory compliance driver from an economic one, insist the cheaper alternatives are priced first, and set the practice that stops the next placement being an accident nobody can afford to undo.

## What data gravity actually is **Data gravity** is the observation that a store gets harder to move as it grows — not only because there are more bytes, but because more things attach to it. Every service that reads it, every pipeline that feeds it, every report that queries it and every identity that is allowed near it becomes part of the move. The cost grows with size *and* with the number of attachments, and the second term is usually the one that surprises people. It also has a direction. Traffic leaving a region is charged, while traffic arriving generally is not, so the physical relocation is priced in the expensive direction. Data gravity is not a technical impossibility — it is a **priced, risky, one-time cost** that grows over time, which is precisely why a region choice made casually at the start becomes a decision nobody wants to revisit. ## Frame it as a comparison ### The one-time cost of moving - **Transfer**, charged per unit on the way out, over the whole store. - **Engineering time** to build the move: the copy mechanism, the consistency plan, the verification, the rollback. - **A cutover**, which is either a window of unavailability or a period of dual operation with reconciliation afterwards. - **Risk**, which is the term most often left at zero and rarely is: a cutover of a large live store is one of the higher-variance operations a team performs. - **Everything attached**: every consumer repointed, every credential and network path reissued at the destination, every scheduled job checked. ### The recurring harm of staying - **Latency** that users pay on every interaction, forever, and that no tuning removes. - **A rate gap** paid every month, if the current region is the expensive one. - **A compliance exposure**, if an obligation now applies that did not when you chose. - **Constraints on what you can build**, if the region lacks services or hardware generations you now need. ## The decision this actually produces 1. **Is there a compliance driver?** If an obligation now requires the data elsewhere, this is not an economic comparison. Plan the move; the only question is how. 2. **Is the harm growing or flat?** Harm that scales with a user base you expect to grow justifies paying a cost that also grows with delay. Flat harm on a stable system often does not. 3. **Price the cheaper answers first.** Two are usually available: move only the latency-sensitive path so the far-away round trip stops being on the user's critical path while the store stays; or leave the existing store where it is and direct *new* growth to the better-placed region, accepting that you now operate in two places. 4. **If you move, move once and verify.** Replicate to the destination, verify completeness and consistency there, cut over with a tested way back, and decommission only after the new placement has survived real traffic. The outcome is legitimately "stay" more often than teams expect. A placement that is merely suboptimal, on a system whose growth has flattened, rarely repays a high-variance migration. ## What you would do differently next time | Practice | What it buys | |---|---| | Treat the region as a parameter, not a constant | The next deployment is a decision, not an inheritance | | Ask about residency obligations before launch, not after | The filter is applied when it is free to apply | | Keep the store beside the work that reads it | Avoids inheriting a cross-region round trip and charge | | Notice when a second location starts accumulating data | Gravity that nobody chose is the worst kind | | Record why the region was chosen | The next team can tell a decision from an accident | ## The judgement to demonstrate The answer an interviewer is listening for is not "move it" or "leave it". It is that you can name the one-time cost and the recurring harm in the same units, separate the mandatory driver from the economic ones, and reach for the two cheaper alternatives before the migration. And that you understand what made the decision expensive in the first place: not the size of the store on its own, but everything that grew up around it while nobody was treating the region as a choice.

  • Which part of the move cost is most often underestimated?
    Everything attached to the store. The bytes are a line you can calculate; the consumers, pipelines, scheduled jobs, credentials and network paths that all have to cut over consistently are discovered one at a time. That discovery, plus the reconciliation after a dual-running period, is usually larger than the transfer charge.
  • When is "stay where we are" the right call?
    When no obligation forces the move, the harm is flat rather than growing, and a cheaper structural change removes most of the pain — typically getting the latency-sensitive path closer while leaving the store put. A high-variance cutover of a large live store needs a benefit that keeps paying, not a tidier diagram.
  • How do you stop the same situation recurring in the new region?
    Make the placement explicit and revisitable: region as a parameter rather than a constant, obligations asked about before launch, the store kept beside the work that reads it, and a recorded rationale. Then watch for data accumulating anywhere nobody decided to put it, because unchosen gravity is the expensive kind.

Moving house is cheap while you own a suitcase and expensive once you own a workshop — and the movers bill you on the way out, not on the way in.

saying these in an interview costs you the question

  • Calls the move technically impossible rather than expensive
  • Counts only the bytes, not everything attached
  • Assumes transfer is charged on the way in
  • Migrates for tidiness with no growing harm
  • Skips the cheaper option of moving only the latency-sensitive path
  • Plans a cutover with no verified way back