A marketplace expanding across cities must decide what is centralised and what is devolved. What principle draws the line?
Show the full answer Hide the answer
The principle
Centralise where inconsistency imposes cost on people other than the decision-maker; devolve where the decision-maker bears the consequence alone.
Applied to a multi-city marketplace:
- Centralised: the platform itself — matching, pricing engine, order state machine, payments, applications, data platform, infrastructure. One codebase, one deployment, one on-call.
- Devolved as configuration: pricing coefficients, service boundaries, category definitions, operating hours, compliance parameters, payment methods, language.
- Devolved as operations: supply acquisition, provider support, partnerships, regulatory relationships — genuinely human and genuinely local.
The test
How long from a decision to launch in a new city, and how much of that is engineering? A mature platform answers "days, and none."
If launching requires engineering work, expansion speed is bounded by engineering capacity, which becomes the constraint on the business's growth — and that is an architectural failure expressed as a commercial one.
What makes it hard
- The second city reveals what varies, and it is never what was predicted. A configuration system built before the second instance is flexible along the wrong axes, which is the rule of three applied to geography.
- Genuinely different market structures occasionally need more than configuration, and the discipline is to resist forking — one fork becomes two, and then the platform is several products.
- City must be a first-class data dimension from the first row, since retrofitting a partition key into a live schema is one of the genuinely painful migrations.
The organisational half that determines success
A local operations team that can change parameters without engineering. If every parameter change is a deployment, the central team becomes a queue and cities work around it.
That requires the configuration to be validated, bounded, auditable and reversible — real engineering work, and the difference between a configurable platform and a dangerous one.
The general form
This is the same decision as standards versus autonomy in an engineering organisation, and the same principle applies: centralise the small set where inconsistency is genuinely costly, devolve everything else, and make the centralised path the easiest one so that compliance does not depend on enforcement.