Scaling from MVP to 100K Users Without Rebuilding

Founders fear rebuilding. Good early choices reduce that risk. This note covers database choice, service boundaries, caching, and a horizontal scaling path so you can grow without a full rewrite.

Choosing the right database early

Use a relational database for the ledger and core transactional data; avoid using only a document store for money. Plan for partitioning (e.g. by tenant_id or account_id). Use connection pooling and read replicas where needed. Choose a database that supports your target scale and consistency needs.

Avoiding monolith traps

Keep clear module boundaries inside the monolith so you can extract services later. Do not share databases across domains; use APIs or events. Avoid global mutable state. This makes it possible to split into services without a big bang.

Service boundaries

Identify bounded contexts: payments, ledger, lending, notifications. Each has its own data and API. Communicate via events or well-defined APIs. Do not create a distributed monolith (tight coupling, shared schemas).

Caching strategies

Cache read-heavy, non-authoritative data (e.g. product config, rates). Do not cache the ledger as the source of truth; use it for balance snapshots with clear invalidation. Use cache-aside or read-through; set TTLs. Invalidate on write.

Horizontal scaling path

Stateless services scale by adding instances. Database scales by partitioning and read replicas. Queue workers scale by adding consumers. Design for this from the start: no local state, idempotent processing, and partition keys that distribute load.