Should you
use it?
The tools engineers argue about, answered the way a senior engineer would over coffee: a plain verdict, the cases where it earns its keep, the cases where it is the wrong call, and the mistakes people make reaching for it.
Should you use a message queue? verdict
Yes, for any work that can finish after the user has their answer — emails, image processing, syncing other systems. No, if the caller needs the result to keep going; then a queue only adds latency and new ways to fail.
Should you use microservices? verdict
Not until you have separate teams stepping on each other in one codebase. Start with a well-organised monolith and split out a service only when a specific part needs its own scaling, its own team, or its own release schedule.
Should you use NoSQL? verdict
Default to relational; reach for a specific NoSQL store only when a named access pattern demands it. A well-tuned Postgres carries most products further than the hype admits — switch when you can point at the workload a particular store serves better, not at scale you might have one day.
Should you shard your database? verdict
Not until one machine cannot keep up. Exhaust read replicas, indexes, caching, and a bigger box first. Sharding is the heaviest, most irreversible tool in the drawer.
Should you add a cache? verdict
Yes, when the same expensive answer is read far more than it changes — but only after you can measure the slow path. Caching trades a little staleness for a lot of speed, and invalidation is the bill.
Should you use a CDN? verdict
Almost always yes if you serve static assets to users in more than one region. It is cheap, it cuts latency, and it shields your origin from the crowd.
Should you use GraphQL? verdict
No for most APIs — default to plain REST, which is less to build, cache, and operate. GraphQL earns its place when several different front-ends each need different slices of the same data and fixed endpoints have become a constant fight.
Should you use Kubernetes? verdict
Not until you run a real fleet — many services across many machines, with multiple teams deploying independently. Until then a PaaS or a few VMs is the better answer; the operational cost of Kubernetes is real, and at small scale it outweighs everything it gives back.
Should you use a load balancer? verdict
Yes, the moment you run more than one copy of a service. It spreads traffic, routes around dead instances, and lets you deploy with no downtime. Table stakes, not an optimisation.
Should you accept eventual consistency? verdict
Yes, for soft data where a brief disagreement is harmless — counts, feeds, presence — because it buys real speed and availability. Never for exact values like money, stock, or uniqueness. Decide field by field, not system-wide.
Get the intuition first, then decide.
Every guide links to the plain-English explainer for the thing it weighs, plus a deeper page when you want the mechanics. Read the verdict for the quick answer; follow the links when you need to defend it.