Stop building like a unicorn
10 replacements for architecture you don't need (yet)
“I’m {FirstName}, and I’m a complex-oholic.”
Say it.
It’s OK, we’ve all been there — prioritizing our ego ahead of our users.
Deep down, we know we were overdoing it all along.
Not ready yet?
All good, it takes time. For now, skim this list and let yourself yearn for the days of yore, when life seemed so straightforward.
Simplify your system
Microservices → modular monolith. If you’re a small team, a monolith with clean module boundaries gives you the same separation of concerns without the network tax (Modular Monoliths).
Abstract base classes → plain functions + composition. If your class has one subclass, it probably shouldn’t be a class (The Composition Over Inheritance Principle).
Feature flag service → Env var +
ifstatement. LaunchDarkly and friends are powerful when you have millions of users. You don’t, soif (process.env.IS_PREMIUM_USER === 'true')is fine (How To Build Feature Flags Like A Senior Dev In 20 Minutes).Semantic versioning automation →
git tag+ a changelog entry. (Keep a Changelog)GraphQL → REST + JSON. Do multiple clients need different shapes of the same data? If not, a REST API will be easier to build, cache, and debug (You probably don’t need GraphQL).
Event-driven everything → direct function calls. If two things always happen together, just call one from the other and save yourself the tracing scavenger hunt (Method Calls vs Event-Driven Architecture in a Modular Monolith API?).
API gateway → reverse proxy routes. Gateways come with rate limits, middleware, routing, and policies. Your existing proxy can do the essentials with a few config lines (Is an API Gateway a Reverse Proxy?).
Pub/sub →
EventEmitter. Node’s built-in can handle internal pub/sub within a single process without a broker or network hop (Redis pub/ sub vs node event emitter).Polyrepo → monorepo. This’ll cut down your CI configs, versions, PRs and repos. Go further by skipping Nx/Turborepo in favor of a simple
Makefile(Understanding Monorepos).Multi-tenancy → multiple single-tenants. Every unicorn engineer will proudly talk about their journey from single-tenant to multi-tenant. Every tech lead of a graveyard startup will reluctantly admit how they spent too much time optimizing instead of iterating (Choosing the right SaaS architecture: Multi-Tenant vs. Single-Tenant).
Did you reject these indignantly? Perhaps you bristled at the thought of a vet like you doing something so elementary.
Well, hopefully you’ll scale so quickly that you outgrow these script-kiddie tactics in a few months. None of the fancy things is wrong; they’re just wrong now, at this scale.
Just ship and help your users, then let the real problems tell you what to add back.
Complexity has its place.
Just not yet.
The most dangerous thought you can have as a creative person is to think you know what you're doing. Learn tools, and use tools, but don't accept tools. Always distrust them; always be alert for alternative ways of thinking
— Bret Victor, “The Future of Programming”