Architecture Guides

The short answer for each decision

Pick the guide that matches the decision in front of you. Each one lists who every option is best for, the trade-offs of each, a comparison across the same set of dimensions, and related tools. The guides are written as trade-offs rather than single right answers, so each ends with a verdict that names the default most projects start from, not a rule. Here is each verdict on its own; open the guide for the reasoning behind it. Start with the decision, then read the dimensions that matter most for your team.

Monolith vs. Microservices

"Start with a monolith" is close to a consensus recommendation for new projects — the common failure mode is adopting microservices' complexity before the organizational or scaling need that justifies it actually exists. Split out a service when a specific, concrete pain point (independent scaling, independent deployment cadence) makes it worth the operational cost, not preemptively.

REST vs. GraphQL

REST remains the simpler, more broadly applicable default, especially for public APIs and CDN-cached content. GraphQL earns its added complexity when you have multiple genuinely different client types pulling different shapes of data from the same backend.

SQL vs. NoSQL Databases

For most applications, a SQL database (PostgreSQL specifically is a strong, well-established default) is the safer starting choice — you can usually add a specialized NoSQL store (like Redis for caching) alongside it later for a specific need, rather than committing your primary data model to NoSQL upfront without a concrete reason.

SSR vs. CSR vs. SSG

Modern meta-frameworks (Next.js, Nuxt) let you pick per-route rather than committing your whole app to one strategy — use SSG for marketing/content pages, SSR for dynamic-but-crawlable pages, and CSR for authenticated app interiors where SEO doesn't apply.