An interviewer puts this to you - six product teams each keep their own copy of the customer record, synced by events. Finance says the counts never match across three dashboards, and month-end reconciliation takes two people a week. Someone has proposed one authoritative customer service that every product calls synchronously. Talk me through how you would handle it.

What the interviewer is testing

Whether you can separate three questions that the proposal has fused: who may write, where a reader reads from, and what a field means. Weak candidates hear "the numbers do not match" and reach for a single shared service, which answers the second question, is silent on the first and cannot answer the third at all. The interviewer also wants to see whether you price a synchronous shared dependency before recommending one.

The clarifying questions that change the answer

• Which field disagrees? If it is a computed field like "active customer", six teams are computing it six ways and this is a definition problem. A shared service does not resolve a shared disagreement about meaning; it relocates the argument into one team's backlog.
• Is there one writer or six? Six concurrent writers is the actual defect. Copies are fine; concurrent authorship is not. If five of the six only read, the fix is to make that explicit and is nearly free.
• What staleness can each field tolerate? Display name, ten minutes. Credit limit, zero. The answer differs per field, and that is what determines which reads can stay local.
• What read volume and p99 budget? This decides whether a synchronous call is affordable at all.

A strong answer's arc

Name one writer per field with a published owner. Keep the local read copies, because removing them puts a shared service in six critical paths. Fix the meaning by publishing one definition and one reference implementation of the computation rather than one service. Then add a reconciliation job that emits divergence as a continuously visible number, so disagreement is a metric with a threshold instead of a discovery at month end.

The arithmetic that usually ends the synchronous proposal: a shared service measured at 99.95%, placed synchronously in the request path of six products that each manage 99.9%, drags every one of them to about 99.85% - six products made worse to fix a dashboard. A 200 ms p99 on that call is 200 ms off every product's own budget.

Common weak answers

• "Single source of truth, so everyone calls the customer service." Prices nothing, and degrades six products to repair a reporting defect.
• "Event sourcing." A better write log does not decide which of six writers wins.
• "Build a warehouse view." Makes the dashboards agree while leaving product behaviour divergent, so the next complaint arrives from a customer rather than from finance.

What a strong answer adds

The ownership question is organisational: someone has to be accountable for what "active" means, and if no one is, the architecture cannot fix it. The cost is quantified - two people for a week each month is roughly half a full-time engineer a year, and that is the budget the fix has to come in under, which rules out a multi-quarter programme. And the first move is sequenced to be cheap and reversible: freeze writes to five of the six copies and watch what breaks for a month, before anyone builds a service. If nothing breaks, you have the answer at almost no cost. If something does, you have learned which team genuinely needs write access, which is the fact the whole design turns on.