“Like FAANG,” Without the Cargo Cult: Bring the Context With the Practice

“We want architecture like FAANG” sounds ambitious. It does not, however, state a requirement or define success. FAANG itself is a convenient label for several large technology companies, not a shared architecture standard.

The useful question is not “How do we copy their diagram?” It is: what problem will this practice solve for us, and are we prepared to pay for the complexity it introduces?

A practice only works within its context

Design documents, an internal developer platform, microservices, or Kubernetes can all be reasonable choices. Their value depends on the conditions around them:

• how many teams need to change the system concurrently;
• where the real domain boundaries are;
• which components need independent releases or scaling;
• how important availability, failure isolation, and recovery speed are;
• whether the team can observe and operate a distributed system;
• what cost of change the product can sustain.

At a global technology company, a practice may reduce coordination across hundreds of teams. In a single product unit, the same practice may create a new platform, several new responsibilities, and more failure modes without removing a real constraint.

Copying the artefact without the reason it emerged is like copying a treatment without the diagnosis.

When good intentions create accidental complexity

No team begins with the goal of making a system harder to change. They want better reliability, faster delivery, or room to grow. Trouble begins when a decision is based on a technology’s reputation rather than an observed constraint.

Common signals include:

• services are separate but still ship as one coordinated release;
• a component has no clear owner, SLO, or recovery procedure;
• a design document names the chosen technology but omits alternatives and trade-offs;
• the platform requires more support than the products it is meant to enable;
• infrastructure is built “for the future,” but nobody has defined what would make that future arrive;
• the team cannot name the product or operational metric the decision should improve.

A separate repository does not create autonomy. A message broker does not create resilience by itself. An orchestrator does not replace operational discipline. These tools produce value only when ownership, observability, and the change process are designed with them.

A composite case

The following is not a story about one project or a precise report from a single company. It is a composite of patterns I have encountered in architecture reviews.

A team split a system into services, introduced several mandatory approval steps, and built a shared platform. The intention was sound: enable independent releases and make operations more predictable. Over time, it became clear that most services still changed together, ownership boundaries were unclear, and incidents crossed several teams without a single accountable owner.

The recovery did not begin with another rebuild. The team:

1. mapped services to business capabilities and owners;
2. identified components with no independent lifecycle;
3. recombined components where separation produced no measurable benefit;
4. assigned SLOs, on-call duties, and recovery procedures to explicit owners;
5. kept only the control points tied to a defined risk.

The outcome was not a “perfect architecture.” It was a shorter chain of responsibility and a clearer path for changing the system—which was the original goal.

Five questions before adopting someone else’s practice

Before implementing a solution because a large company uses it, run a short check.

1. Which constraint are we removing?

Describe an observable condition: releases block one another, one component carries disproportionate load, incidents propagate across domains, or every change requires several teams. “We need a modern architecture” does not pass this test.

2. How will we know it worked?

Choose one or two metrics linked to the goal: change lead time, change failure rate, recovery time, share of independently delivered changes, or infrastructure cost per useful workload.

3. What is the full cost?

Implementation is only one part. Include the platform, observability, test environments, security, training, on-call work, upgrades, and coordination among owners.

4. What conditions made the practice successful at its source?

A public engineering talk usually shows the outcome. It may not show the size of the platform team, the accumulated tooling, or the organisational boundaries that made it possible. If those conditions cannot be reproduced, the practice must be adapted.

5. What is the smallest reversible test?

Try one domain boundary, automate one delivery path, introduce a lightweight ADR, or test one service that genuinely needs independent scaling. A bounded experiment produces evidence and preserves a path back.

What is worth learning from strong engineering organisations

The most transferable lesson is not the shape of their systems. It is the quality of their decisions:

• make context and trade-offs explicit;
• assign ownership for the outcome;
• test architecture hypotheses with metrics;
• automate repeatable controls;
• design operations together with delivery;
• revisit a decision when its assumptions change.

These habits help both a small team and a large enterprise. Their implementations will differ, but the principle is stable: complexity should purchase a specific capability for the system or the organisation.

A decision that fits our team

Architecture maturity is not the number of patterns a team has adopted. It is the ability to explain why a decision fits this product now, what it costs, and when it should be reconsidered.

So I would neither accept nor reject “Let’s do it like FAANG” on the spot. I would ask:

“Which of our problems will this solve, and how will we verify that?”

The question does not reduce the ambition. It turns that ambition into an engineering decision.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP