Stop copying big-tech platform architecture: right-size to your scale

A lot of platform over-engineering starts with a diagram that looks serious. A small team has a few services, a modest growth curve, and perfectly ordinary operational needs, but the design doc still reaches for the full hyperscaler silhouette: Kubernetes everywhere, a service mesh, Kafka, multi-cluster, and a bespoke internal platform before anyone has proved they need one. The problem is not that those tools are bad. It is that they are answers to constraints most teams do not have. Right-sizing platform architecture means copying the principles behind big-tech systems, not the stack itself.

That becomes expensive quickly because complexity is not free. Every extra control plane becomes another upgrade path, another source of pages, another thing a new engineer has to understand before they can safely ship a change. Big companies take on that cost because, at their scale, it often pays for itself. Small and mid-sized teams usually take it on up front and hope the benefits show up later.

They often do not.

Big-tech architecture is the output of big-tech constraints

It helps to say the quiet part out loud. Google, Amazon, and the rest did not end up with sprawling platform stacks because they enjoy making life difficult. They built those systems under pressures most teams will never see all at once:

• traffic and data volumes that make single-node or single-database assumptions collapse
• hundreds of teams that need to change software independently
• regulatory or blast-radius boundaries that force hard isolation
• dedicated platform and reliability teams to operate the machinery

If your team has three product engineers and one person who gets the on-call phone, you are operating under a different set of forces. Copying the architecture without copying the forces is how you end up with enterprise-grade overhead and startup-grade staffing.

That is also the practical reading of Conway’s Law. System design follows communication structure. A microservice estate with separate deployment pipelines, cross-cutting policy layers, and multiple control planes assumes an organisation shaped to own those boundaries. If you do not have that organisation, the elegant diagram turns into one team carrying all of the complexity by hand.

Copy the principles, not the implementation

The useful parts of big-tech engineering are usually the ideas underneath the stack choice.

You can borrow those almost anywhere:

• reduce cognitive load so engineers can ship without learning every platform detail
• improve feedback loops so changes are cheap to validate and rollback
• create clear boundaries between services, teams, and operational ownership
• standardise the paved road so the safe path is also the easy path
• treat cost as a design constraint, not something to apologise for later

What does not travel as cleanly is the implementation detail. Service mesh, multi-cluster, event streaming everywhere, and a bespoke internal developer platform are all legitimate responses to particular thresholds. They are poor defaults.

This is where Dan McKinley’s Choose Boring Technology still lands so cleanly. His line about companies having roughly three innovation tokens has aged well because the underlying point is still right: novelty is expensive, and you should spend it where it creates advantage rather than where it merely creates architecture. “Boring” in McKinley’s sense is not old or unfashionable. It is technology whose failure modes are already well understood.

For platform teams, that is a strong default. If the thing you are building is not your differentiator, buying more operational complexity than you need is rarely a flex. It is a loan.

“You are not Google” is a useful design rule, not a slogan

Oz Nova’s You Are Not Google remains one of the clearest antidotes to architecture cargo culting because it forces a more honest sequence of questions. What problem are you actually solving? Which candidate solutions exist? What historical pressure produced the famous answer everyone keeps citing? Does that answer fit your team, budget, and operational maturity now?

Those questions are annoyingly effective because they make a lot of platform theatre disappear.

A Kubernetes platform is a good example. Plenty of teams do need Kubernetes. Plenty also adopt it because it feels like the proper destination for anything serious. The real question is not “is Kubernetes modern?” It is “what operational problem does this solve for us today that simpler deployment machinery does not?” If the answer is mostly social proof, that is a warning light.

The same applies higher up the stack. A bespoke internal platform can be the right move when many teams need a common workflow and the cost of hand-held support keeps rising. But Team Topologies’ thinnest viable platform is a better starting point than an immediate platform product. Sometimes the right platform is a template, a few scripts, and good docs. It does not have to begin life as an ecosystem.

The Prime Video story is a correction, not a manifesto

The most abused recent example in this space is Prime Video’s write-up on reducing the cost of one monitoring service by more than 90%. The point of that post was not “Amazon abandoned microservices” and it certainly was not “monoliths always win”. It was narrower, and more useful.

One team had built a distributed serverless design around Step Functions, Lambda, and S3. At the workload they were handling, the orchestration overhead had become the cost problem. They moved to a single process running on ECS and passed data in memory instead of via a chain of external services. The result was a cost reduction above 90% for that tool.

That matters because it shows what right-sizing actually looks like in practice. The original design was valid in the abstract. It was just mis-sized for the workload and economics in front of the team. Adrian Cockcroft’s corrective take on the reaction was useful here too: this was a refactoring decision inside one service, not a grand ideological retreat.

The lesson is not “always build a monolith”. It is “distributed systems premiums only make sense when you are actually collecting the benefit”.

Martin Fowler has been making the same point for years. Monolith First is still one of the sanest defaults in software architecture because a modular monolith lets you prove boundaries before turning them into network calls. You can extract a service later. You cannot cheaply un-distribute a badly fragmented system that nobody really needed.

A right-sizing table for platform teams

If you want one decision aid from this post, make it this: treat big-tech patterns as threshold tools, not identity markers.

Pattern people cargo-cult	Right-sized default for most teams	Real signal the bigger pattern may now pay off
Service mesh	Use ingress, NetworkPolicy, and straightforward app-level telemetry first. Add mTLS or traffic shaping only when you can name the requirement.	You need per-service identity, consistent mTLS, or progressive traffic control across many teams and many services.
Multi-cluster Kubernetes	Start with one well-run cluster and strong namespace, RBAC, quota, and environment boundaries.	You have hard isolation needs: data residency, materially different blast radii, or control-plane scale limits.
Kafka for everything	Start with a managed queue, an outbox pattern, or even Postgres when throughput and replay needs are modest.	You genuinely need a durable, replayable event log with multiple independent consumers and sustained high throughput.
Bespoke internal developer platform	Start with a thinnest viable platform: templates, automation, docs, and one paved path that removes toil.	Many teams are repeating the same workflow, support demand is compounding, and a platform product will clearly save more time than it costs to run.
Microservices from day one	Start with a modular monolith and explicit internal boundaries.	Teams need independent deployability, boundaries are already clear, and you have the operational discipline to support distributed systems well.

This is also where the DORA research is often flattened into the wrong slogan. High-performing teams benefit from loose coupling and independent deployability. That does not automatically mean “split everything into microservices”. You can get plenty of that benefit from a well-structured monolith, a clean delivery pipeline, and sensible ownership boundaries.

The label matters less than the change cost.

Cost, team shape, and on-call load should be first-class inputs

Werner Vogels’ Frugal Architect material is useful beyond AWS because it frames architecture as a series of trade-offs rather than a hunt for the most sophisticated-looking answer. That sounds obvious, but teams forget it surprisingly easily when a design starts accumulating fashionable parts.

A few questions cut through the theatre quickly:

• What does this add to the pager surface area?
• Who upgrades it, patches it, and debugs it at 02:00?
• What skill set does it require from every new engineer?
• What failure mode becomes easier because we adopted it?
• What failure mode becomes harder or more likely?
• Could a simpler design buy us another year before this complexity is justified?

If those questions make the design feel awkward, that is usually a useful signal rather than conservatism.

This is especially true in platform engineering because platforms quietly multiply costs across the organisation. A hard-to-understand abstraction does not stay local to the team that built it. Every product engineer pays rent on it.

When the bigger architecture is the right call

None of this is an argument for permanent smallness or for avoiding ambitious systems. Some teams absolutely do cross the threshold where the heavier pattern is worth it.

You are probably getting there when several of these are true at the same time:

• multiple teams are blocked on each other because deployments cannot move independently
• reliability problems are coming from shared blast radius rather than application bugs
• platform support has turned into a queue because manual help does not scale
• data residency, compliance, or tenancy requirements demand hard technical boundaries
• workload volume has made the simpler option materially more expensive or less reliable

At that point, more machinery can be the cheaper choice overall. But it is still better to adopt it deliberately than to inherit it by imitation.

That is the part people miss when they turn “choose boring technology” into a bumper sticker. McKinley’s innovation tokens exist so you can spend them where they matter. The platform question is whether you are spending one on a real constraint or on architecture envy.

The sophisticated choice is often the smaller one

The cheapest architecture that meets your actual constraints is not the amateur option. Usually it is the disciplined one.

Small teams do not fail because they lacked enough control planes. They usually fail because they made delivery too slow, operations too fragile, and ownership too muddy for their actual size. Big-tech architecture can solve those problems at big-tech scale. At smaller scale, it often creates them.

So copy the habits that travel: clear interfaces, good defaults, fast feedback, cost awareness, and platforms that remove toil rather than advertise sophistication. Leave the rest until the numbers, the team shape, and the pager all agree that you have earned it.