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
Almost certainly not yet. 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
It depends on your access pattern, not on scale hype. If your data is relational and you ask varied questions of it, stay with SQL. Pick a specific NoSQL store when its shape and its queries genuinely fit yours.
Should you shard your database? verdict
Not until one machine genuinely 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
It depends on your clients. GraphQL pays off when many different front-ends need different slices of the same data. For a simple, stable API, a plain REST endpoint is less to operate.
Should you use Kubernetes? verdict
Probably not for a small product. It earns its keep at fleet scale, but the operational cost is real, and a PaaS or a few VMs is often the better answer until you outgrow them.
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
It depends on the data, field by field. For soft values where a brief disagreement is harmless, eventual consistency buys speed and availability. For exact values that must be right on every read, do not.
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.