Designing scalable digital platforms
Platform architecture is a series of small, disciplined bets. Here is how we think about the first ten.
Platforms fail slowly, then all at once. The failure is almost never the framework choice. It is almost always the compounding weight of decisions that were reasonable in isolation and disastrous in aggregate.
The frame we work to is simple: every architectural decision is a bet, and the job is to keep the bets small, reversible and honest.
The first ten bets
- One language and one runtime for the core services. Polyglot is a hiring plan, not an architecture.
- One data store as the source of truth for each domain. Every additional store is a reconciliation problem in waiting.
- Contracts before code. If two teams cannot agree on the interface in a document, they will not agree on it in the deploy.
- Async by default at the domain boundary. Synchronous coupling is the fastest path to a cascading incident.
- One deploy pipeline. If the second one appears, the first one is not doing its job.
- Observability as a product, not a feature. Metrics, logs and traces belong to a team, not to every team.
- One identity model across the platform. Two is a merge story you will lose.
- Feature flags for change, not for testing. The moment a flag becomes permanent, delete it or promote it to configuration.
- A migration story for every schema, from day one. The teams that ship fastest are the ones that never fear a migration.
- A written architecture decision record for every one of the above. Future-you will not remember why, and future-them will not either.
What we do not do
We do not build for the scale we hope to reach. We build for the scale we can prove we need, with a clear next hop. The number of platforms that failed under the weight of their own abstraction, waiting for traffic that never came, is longer than the number that failed because they were too simple.
“The best platforms are boring on the inside and interesting on the outside.”
The uncomfortable part
Most of this is not new. Most of it is not glamorous. All of it is the difference between a platform that compounds and a platform that becomes the reason for the next re-platform. Discipline in the first ten decisions is worth more than heroics in the next hundred.
Frequently asked
01When should a team actually start designing for scale?
Later than most teams do, and in fewer places. The decisions genuinely expensive to revisit are the data model and the tenancy model; nearly everything else can be changed once you know what the load looks like. Building for a scale you have not reached spends runway on optionality you may never use.
02What breaks first when a platform grows?
Usually the database and whatever humans were quietly doing by hand. The technical ceiling is visible and gets attention; the operational one does not, until a process that worked at fifty customers collapses at five hundred. We look at both when we assess a platform.
03Microservices or a well-structured monolith?
A clear monolith, until team structure or a genuinely different scaling profile justifies splitting something out. Most of the benefit attributed to microservices comes from clean boundaries, which a monolith can have. Most of the cost arrives on day one, whether or not you needed it.
04How do you keep a platform maintainable as the team changes?
By making the system legible: boundaries that match how people describe the business, tests that explain intent, and documentation written for the engineer who joins next year. Platforms rarely rot because of one bad decision. They rot because nobody left behind the reasoning for the good ones.
