Backend Scaling Decision Matrix (0 to 1M Users)

Topic by topic

Every topic on the map with its description, what to know and resources — in one list.

1. 01Stage 1: Clean Modular Monolith (0 - 50K DAU)

   • Modular Monolith Architecture· Core+

     Build a single monolith where domain boundaries are isolated by folders (modules) using Fastify, NestJS, Go, or Django. Inter-module communication happens via in-memory function calls, not over the network (0ms latency).

     What you should know

     • Modules never query each other's database tables directly; they interact through strict public service interfaces.
     • A single well-configured server with properly indexed PostgreSQL easily handles 3,500+ requests per second (RPS).
     • A single Docker image and CI/CD pipeline lets you ship updates in seconds.

     Resources

     • System Design Primer· Guide
   • Database Indexes & Connection Pooling· Core+

     90% of slowing systems suffer from missing indexes and exhausted connection pools, not insufficient CPU.

     What you should know

     • Add B-Tree indexes on all foreign keys and common WHERE / ORDER BY columns; verify query plans with EXPLAIN ANALYZE.
     • Place PgBouncer in front of PostgreSQL to multiplex thousands of client connections into 50-100 database connections.

     Resources

     • Use The Index, Luke (SQL Index Guide)· Guide

2. 02Stage 2: Relieve Database Pressure (50K - 150K DAU)

   • Redis Cache-Aside Pattern· Core+

     Cache frequently read but rarely changed data (user profiles, configs, home feed) in Redis RAM (dropping latency from 450ms disk I/O to 1.2ms RAM hits).

     What you should know

     • Check Redis first (Cache Hit). If missing, fetch from database, populate Redis, and return (Cache Miss).
     • Always attach sensible TTLs to cache keys; unbounded caching causes memory bloat.

     Resources

     • Redis Cache-Aside Pattern Documentation· Docs
   • Read / Write Splitting & Read Replicas· Nice to have+

     Web traffic is typically 85% reads (SELECT) and 15% writes (INSERT/UPDATE). Offload read traffic to replica instances.

     What you should know

     • Route write operations to the primary DB, and offload read-heavy analytics and search queries to read replicas.
     • Account for replication lag in critical user journeys (e.g. reading immediate post-checkout order records).
   • CDN & Static Asset Distribution· Core+

     Cache images, fonts, JS/CSS bundles, and public API responses on Cloudflare Edge to eliminate origin server hits.

     What you should know

     • Requests resolve in 10-20ms at global edge nodes before ever reaching your origin server.

3. 03Stage 3: Asynchronous Message Queues (150K - 500K DAU)

   • Job Queues with BullMQ / RabbitMQ· Core+

     Never execute any task taking longer than 50ms synchronously inside the HTTP request-response cycle.

     What you should know

     • When a user triggers an action, the API enqueues the job and responds with '200 OK - Accepted' in 18ms.
     • Dedicated background workers process the queue; if a worker crashes, queued jobs persist safely.

     Resources

     • BullMQ Documentation (Redis-based Queue)· Docs
   • Retry Strategy & Dead Letter Queue (DLQ)· Core+

     When a 3rd party service (SendGrid, Stripe) experiences downtime, don't fail user requests; retry smartly in background.

     What you should know

     • Apply Exponential Backoff with jitter to retry transient failures safely.
     • Route permanently failing jobs to a Dead Letter Queue (DLQ) and fire an operational alert.

4. 04Stage 4: Domain Microservices & Event-Driven (500K+ DAU)

   • Domain-Driven Service Decomposition· Core+

     Don't decompose the whole system overnight; extract the most autonomous domains first (Auth, Payments, Notifications).

     What you should know

     • Each service must own its private database (Database-per-Service); shared databases are an anti-pattern.
     • Split into microservices when 5+ independent teams need to deploy autonomously without release locks.

     Resources

     • Microservices Patterns (Chris Richardson)· Guide
   • Event Streaming with Apache Kafka· Core+

     Synchronous HTTP calls between microservices cause cascading failures; migrate to an asynchronous Event-Driven architecture.

     What you should know

     • When an order is created, emit an 'OrderCreated' event instead of calling 5 downstream REST endpoints.
     • Use the Transactional Outbox Pattern to guarantee atomic database updates and event publishing.

     Resources

     • Apache Kafka Official Documentation· Docs
   • Distributed Tracing & OpenTelemetry· Nice to have+

     When a request takes 4 seconds across 15 microservices, Correlation IDs and OpenTelemetry tracing are the only way to pinpoint the bottleneck.

     What you should know

     • Generate a unique Trace ID at the API gateway and propagate it across all downstream service headers.