FAANG the Russian Way: The Cult of Canon and Antipatterns Born of Good Intentions

Introduction

Not long ago, one of the requests I got landed as something almost sacred:

— "We want to build architecture like FAANG."

And it always sounds like the opening scene of a disaster.

Why?

Because I've seen too many times how that phrase becomes the beginning of the end — and the team only realizes it when it's already too late to fix. By the time the architecture audit shows up, the resources are spent, the deadlines are burned, and the word "rebuild" sounds like a death sentence for the budget. The moment someone utters "like FAANG," that very feeling hangs in the air: welp, that's it, we're done for.

Yes, it sounds pretty. But in practice, under the "like FAANG" banner, people split into four camps.

• The clueless — "Who? Where? What even is that?"
• The know-it-alls — certain they know everything and ready to build canonical palaces right up until the first taste of pain in production.
• The battle-scarred — already built "by the book," got burned, and now design based on their scars.
• The Actually-Um Architect — read a couple of Habr articles, armed himself with common sense, and is convinced he's saving civilization.

Recognize yourself? No offense — pure observation 😏

If you live by the "FAANG template," the script is usually the same: microservices for the sake of microservices, diagrams for the sake of diagrams, architecture discussions that run longer than the releases, and off to the side sits a sad old monolith that still works and still makes money.

I'm not a theorist and not an "architecture guru." I'm one of the battle-scarred, someone who spent the last few years hauling real systems on my back: big, noisy ones, with a million integrations and compromises. And there, in the trenches, I understood a simple thing: technological fashion is the worst client architecture can have.

We learned "design patterns," "design docs," and the sacred rituals of "code review by checklist." But we often forget to ask one basic question:

- "Do we actually need this at all?"

I don't claim to hold the truth. These are just observations about how good intentions — to do it "the smart way" and "by canon" — turn into antipatterns, and then teams spend their nights trying to fix the beauty they built themselves. In short, this article is a set of thoughts about a sore spot.

1. Why We Love Canon So Much

We love it when there's a ready-made answer. Canon is about safety: no need to think, no need to argue, just do it "like in the book." And if things go sideways — you can always say:

- "Well, I did it like FAANG!"

That's our IT talisman. The sacred "by the standard." In a world where tasks fly by faster than commits, you want to believe that somewhere out there is an instruction manual that will spare you the pain and the chaos.

This love has three roots.

The first is fear. The fear of being wrong, of not being "by the textbook." It's easier to hide behind a link to Medium and a pretty diagram than to admit: we're doing this for the first time.

The second is belief in miracles. We all secretly dream of a silver bullet: install Kafka, add Kubernetes, plug in GraphQL — and the business will take off. Only later does it turn out that we have exactly one Kafka, nobody's monitoring the Kubernetes, and every last microservice soul is calling GraphQL.

The third is the cult of perfection. IT folks don't know how to "build it and forget it." We build — and then polish endlessly. Architecture stops being a tool and becomes an end in itself.

In reality it's simpler: we love canon because it gives us the illusion of control. Follow the pattern and the chaos seems to retreat. But reality never read your books. The business has its own tempo, the team has its own experience, the infrastructure has its own constraints. And that's when canon turns into a beautiful way to die slowly but systematically.

I've watched teams grab hold of the "right architecture," spend months rebuilding, and then the business had already turned right while they were still marching left — strictly by the guide. That's the moment you hear the classic line:

"We did it like FAANG, but somehow it got worse." The answer is simple: you took a ritual, not an approach.

And rituals in engineering live exactly until the first load hits production.

2. FAANG Is Not About Diagrams, It's About Culture

FAANG isn't about microservices, it's about an engineering culture where every decision is deliberate rather than trendy. There, design docs work because discussing architecture is part of the process, not a rare ritual. Code review isn't punishment — it's a way to grow a developer. Microservices aren't a fetish but a tool justified by scale, where hundreds of teams commit in parallel without stepping on each other.

Now — back to our reality.

A company of twenty developers tries to live "like FAANG":

• introduces design docs — and spends a week agreeing on a table name;
• sets up CI/CD — but is too scared to ship a release without a manual check;
• splits the system apart — and ends up with seven repositories where the same bugs get fixed by hand.

And all of it comes not from stupidity, but from the desire to do it "right."

FAANG practices aren't magic. They grew where culture rests not on slogans but on maturity. There, a developer knows why they need that document. There, an architect is responsible not just for the beauty of the diagrams but for the team understanding the decision. With us it more often turns into theater: the costumes are expensive, the stage is gorgeous, and the audience (in the person of the business) walks out at intermission anyway.

3. How to Tell You're Already Trapped

You can spot a team that's slid from architecture into cult by the symptoms. If the answer to "why are we doing this?" is "because it's right, because it's in the book, because that's how the big players do it" — congratulations, you're already there. When the word "pattern" comes up more often than "it works," when design docs multiply while the real decisions get made in chat threads — that's the trap. Onboarding lasts longer than the lead's vacation, there are more services than there are people who remember what they're for, and the monitoring stays silent because nobody knows what it's actually responsible for.

In moments like these, all the archetypes show up:

• the clueless nod along without asking "why";
• the know-it-alls quote the canon and build palaces up until the first taste of pain;
• the battle-scarred quietly suggest "a small path that works";
• and the Actually-Um Architect searches Habr for an article titled "How Google Fights Technical Debt."

If everything's perfect in the documentation but production is chaos — you're in architectural theater. Reviews by checklist, incidents on schedule, and "rethinking the architecture" runs longer than the releases.

4. What to Do If You've Ended Up There Anyway

First — don't panic and don't launch a crusade against "the old architecture." Panic breeds a second zoo — one made of old and new. Architecture is treated surgically, not with artillery.

The main thing is to admit you're not in a technical dead end, but in an overdose of decisions. It's not a shortage of ideas, it's an overdose of them. Try not adding, but removing.

Ask the team: which processes do we do "because we have to" rather than because they bring value? If half the answers rest on "that's just how it's done" and "everybody does it" — what you have isn't architecture, it's corporate folklore.

Run a context audit: how many people are actually involved, what are their competencies, how much time goes into maintenance versus development? Usually it turns out a team of six lives by processes built for a hundred, and a release takes weeks because "that's how the big players do it."

💡 A Mini Case from Practice

On one project we started not with "rebuild everything" but with an inventory. We removed two duplicate microservices, gave SLA ownership back to a single owner, cut onboarding from six weeks to two. Not a single diagram got prettier, but the recovery time after an incident dropped noticeably and releases stopped hanging overnight (not exactly like that, but close). Fewer patterns — more value.

Learn to say "no": no to fashion, no to open-ended "refactorings for the greater good," no to rebuilds without new data.

And here's what you should absolutely say "yes" to: yes to transparency, yes to concrete metrics, yes to feedback.

When the architecture feels too right — it means you've already taken a wrong turn somewhere.

5. Why the Best Get It Wrong More Often

The irony is that it's usually the strongest who fall into this trap. The very same "know-it-alls" and "battle-scarred" who already got burned and are now convinced they know how it's supposed to be. They build perfect systems where everything is interconnected and documented. And then the business comes along and says: "Hey, so, we work a completely different way now."

Experience breeds a belief in control, but control without context turns into concrete. Trying to anticipate everything, we create structures that can't be touched. Architectural purity lives until the first change in requirements.

And one more thing: the fear of looking like an amateur. Good engineers love beauty and science, but sometimes they become hostage to them. The result is that the people who are supposed to simplify make things more complex — sincerely wanting to do it "the smart way."

I've seen projects where some of the smartest people turned the system into a showcase of their competencies. Perfect on the diagrams, but in production nobody knows how to maintain it. Because in architecture, as in life, the smarter the person, the more elegant the justification for their mistakes.

Experience without doubt isn't mastery, it's autopilot. It's convenient — until the weather changes.

6. How to Choose Your Own Path

At some point you have to stop playing "catch-up with the industry" and ask:

"So which path is ours?"

Not the one in the articles, but the one that fits your product and your people.

Architecture isn't a recipe, it's a balance of context, people, and common sense. The world doesn't collapse if you didn't adopt yet another pattern. It collapses when you forget why you're building any of it in the first place.

If you're a small team — build architecture so that everyone can understand it. In a corporation — make decisions that can survive the human factor. In a startup — architecture should breathe along with the product, not stand as a monument to the architect's ambitions.

Real maturity isn't in knowing every diagram, it's in the ability to say:

"No, we don't need this yet."

A mature architect builds by reality, not by canon. Their job isn't to impress a conference, but to make sure the system survives the quarter without heroics.

Choosing your own path doesn't mean rejecting progress — it means subordinating it to common sense. Everything else is just pretty set dressing for those who haven't yet learned to doubt.

The Finale

If you've read this far — something struck a nerve. And maybe somewhere in the text you recognized your project, your team, or yourself. That's normal — we've all been through it.

FAANG, canon, "clean architecture" — these are all tools, not commandments. The problem starts when the tool becomes a cult and the solution becomes an end in itself.

A cult demands worship; architecture demands common sense. It only lives where it's allowed to be flexible, grounded, imperfect — but alive.

I've watched teams wreck systems because they tried too hard to make them perfect. And I've watched others pull the business through simply by saying:

"Enough. That's enough."

Perfect systems live in books. In reality, the living ones win. So if tomorrow someone tells you again:

"Let's build it like FAANG," — just smile. And ask: "What for?"

That short word saves more projects than any pattern.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP