Database Architectures
Understanding database architectures helps you design systems that meet availability, consistency, and performance requirements.
When You Need Database Architectures
Understanding database architectures helps you design systems that meet availability, consistency, and performance requirements. Different architectures suit different workloads.
What It Is
Database architecture refers to how a database system is deployed and how data flows between components. Key patterns include: single-node, primary-replica, multi-primary, active-active, shared-nothing, and shared-disk architectures.
How It Works
The choice of architecture depends on your requirements. Single-primary is simplest and works for most applications. Active-active enables multi-region writes but requires CRDT or last-writer-wins for conflicts. Shared-nothing scales best but requires application-level data routing (sharding).
The Decision Framework
- Primary-Replica: One primary handles writes, replicas handle reads. Most common for web applications.
- Active-Active (Multi-Primary): Multiple nodes accept writes. Requires conflict resolution. Used for multi-region deployments.
- Shared-Nothing: Each node has its own storage. Nodes communicate only via network. Highly scalable (Cassandra, CockroachDB).
- Shared-Disk: Multiple compute nodes share a single storage layer. Simplifies data management (Amazon Aurora, Oracle RAC).
- NewSQL: Combines SQL interface with NoSQL scalability. CockroachDB, Google Spanner, TiDB.
What the Industry Uses
Amazon Aurora: Shared-disk architecture — compute and storage are separated. Storage auto-scales across 6 copies in 3 AZs.
CockroachDB: Shared-nothing distributed SQL. Each node owns a range of data, using Raft for replication.
MongoDB: Primary-replica with automatic failover via replica sets. Supports sharding for horizontal scaling.
Performance and Tradeoffs
- Simplicity vs Scale: Single-primary is simple; multi-primary adds conflict resolution complexity.
- Consistency vs Write availability: Active-active enables writes everywhere but risks conflicts.
- Cost: Shared-disk (Aurora) is simpler operationally but costs more than shared-nothing.
Mistakes Engineers Make
- Choosing active-active without a conflict resolution strategy
- Not considering network latency for multi-region architectures
Practice These Interview Questions
- What database architecture would you choose for a multi-region application?
- What is the difference between shared-nothing and shared-disk?
- When would you use active-active replication?
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.
Further Reading
The Real-World Incident That Made This Famous
Understanding Database Architectures became critical after multiple high-profile production incidents at major tech companies. When systems handle millions of users, even small misunderstandings about Database Architectures 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 Architectures because they learned the hard way that ignoring it leads to outages.
The key lesson from these incidents: Database Architectures 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 Architectures differently from textbook definitions. Instead of memorizing rules, they build mental models. They ask: "What problem does Database Architectures 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 Architectures 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 Architectures to real systems and real problems.
Mistake 2: Not discussing trade-offs. Every design decision involving Database Architectures has trade-offs. Discuss what you gain and what you give up.
Mistake 3: Overcomplicating the solution. Start with the simplest approach to Database Architectures that meets the requirements, then add complexity only when justified.
Production Checklist
- Define clear metrics for measuring the effectiveness of your Database Architectures implementation
- Set up monitoring and alerting that specifically tracks Database Architectures-related failures
- Document your Database Architectures design decisions in Architecture Decision Records (ADRs)
- Test failure scenarios related to Database Architectures in staging before production deployment
- Review and update your Database Architectures implementation quarterly as system requirements evolve
- Train new team members on the specific Database Architectures patterns used in your system
Read the original source | Content from System-Design-Overview