Database Scaling
The database is almost always the first bottleneck in a growing system. Knowing the scaling playbook — and the order in which to apply techniques — is.
The Core Idea
Database scaling is the process of increasing a database's capacity to handle more data, more queries, or more concurrent users. It involves vertical scaling (bigger server), read replicas, caching, connection pooling, query optimization, and ultimately sharding.
Step-by-Step Walkthrough
The scaling journey: Most systems start with a single PostgreSQL/MySQL instance. As traffic grows, you add indexes and caching. Then vertical scaling (AWS RDS supports instances with 768 GB RAM). Then read replicas for read-heavy workloads. Finally, sharding when a single primary cannot handle write volume.
The key insight: exhaust simpler options before moving to more complex ones. Many companies run for years on a single database with good indexing and caching.
Why This Approach Wins
- Step 1 - Optimize queries: Add indexes, rewrite slow queries, use EXPLAIN ANALYZE. This is free and often sufficient.
- Step 2 - Add caching: Cache hot data in Redis/Memcached. Reduces database load by 80-95% for read-heavy workloads.
- Step 3 - Vertical scaling: Upgrade to a bigger server (more CPU, RAM, faster SSD). Simple but has limits.
- Step 4 - Read replicas: Route read queries to replicas. The primary handles only writes.
- Step 5 - Connection pooling: Use PgBouncer or ProxySQL to manage database connections efficiently.
- Step 6 - Sharding: Split data across multiple databases. Last resort due to complexity.
In Production
StackOverflow runs its entire site on a single SQL Server instance with good caching and query optimization. Proof that you do not always need to shard.
Shopify scaled from a single MySQL to a sharded architecture using Vitess as traffic grew to millions of merchants.
Pinterest scales their MySQL with custom sharding middleware, placing each user's data on a specific shard.
Tradeoffs and Limitations
- Each step adds complexity: Caching adds cache invalidation challenges. Replicas add replication lag. Sharding adds cross-shard query issues.
- Cost: Vertical scaling is expensive per unit of performance. Horizontal scaling is cheaper per unit but has higher operational cost.
- Diminishing returns: Caching gives the biggest bang for the buck. Sharding gives the least improvement per unit of engineering effort.
Production Gotchas
- Sharding too early — most systems never need it
- Not adding indexes before considering scaling
- Not using connection pooling — many connection issues look like scaling problems
The Interview Angle
- What is your step-by-step approach to scaling a database?
- When would you add read replicas vs sharding?
- How does caching reduce database load?
- What are the tradeoffs of each scaling technique?
Next Up
The Real-World Incident That Made This Famous
Understanding Database Scaling became critical after multiple high-profile production incidents at major tech companies. When systems handle millions of users, even small misunderstandings about Database Scaling can lead to cascading failures that cost millions in lost revenue and erode user trust. Companies like Netflix, Google, Amazon, and Meta have all invested heavily in mastering Database Scaling because they learned the hard way that ignoring it leads to outages.
The key lesson from these incidents: Database Scaling is not just a theoretical concept — it is a practical skill that separates engineers who build resilient systems from those who build fragile ones.
How Senior Engineers Think About This
Senior engineers approach Database Scaling differently from textbook definitions. Instead of memorizing rules, they build mental models. They ask: "What problem does Database Scaling solve? When does it fail? What are the alternatives?" This problem-first thinking leads to better design decisions because every system has unique constraints.
When evaluating Database Scaling in a system design context, experienced engineers consider the failure modes first. What happens when this component goes down? How does the system degrade? Is the degradation graceful or catastrophic? These questions reveal more about your understanding than any textbook definition.
Common Interview Mistakes
Mistake 1: Giving a textbook definition without context. Interviewers want to see you connect Database Scaling to real systems and real problems.
Mistake 2: Not discussing trade-offs. Every design decision involving Database Scaling has trade-offs. Discuss what you gain and what you give up.
Mistake 3: Overcomplicating the solution. Start with the simplest approach to Database Scaling that meets the requirements, then add complexity only when justified.
Production Checklist
- Define clear metrics for measuring the effectiveness of your Database Scaling implementation
- Set up monitoring and alerting that specifically tracks Database Scaling-related failures
- Document your Database Scaling design decisions in Architecture Decision Records (ADRs)
- Test failure scenarios related to Database Scaling in staging before production deployment
- Review and update your Database Scaling implementation quarterly as system requirements evolve
- Train new team members on the specific Database Scaling patterns used in your system
Read the original source | Content from System-Design-Overview
Practical Implementation for .NET Developers
In a .NET application, you would typically implement this pattern using the following approach:
ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.
Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.
Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.
Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.
Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:
Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);
This gives you searchable, structured logs in Azure Monitor or Seq.