Database Architectures: OLTP, OLAP, Replication and Scaling
Compare database architectures for system design: OLTP, OLAP, replication, partitioning, storage engines, consistency models, and scaling tradeoffs.
Quick answer: Database Architectures: OLTP, OLAP, Replication and Scaling
Database Architectures: OLTP, OLAP, Replication and Scaling is covered here as a practical system design concept. Compare database architectures for system design: OLTP, OLAP, replication, partitioning, storage engines, consistency models, and scaling tradeoffs. Use it to understand the Databases idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
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?
Original DosiBridge notes for Database Architectures: OLTP, OLAP, Replication and Scaling
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Database Architectures: OLTP, OLAP, Replication and Scaling is to connect the concept to a data path where correctness, access pattern, and future migrations matter more than benchmark numbers. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Query Shape: For Database Architectures: OLTP, OLAP, Replication and Scaling, decide the query shape before choosing tools; otherwise the design looks clean but fails when database changes.
- Write Amplification: For Database Architectures: OLTP, OLAP, Replication and Scaling, decide the write amplification before choosing tools; otherwise the design looks clean but fails when architectures changes.
- Replication Lag: For Database Architectures: OLTP, OLAP, Replication and Scaling, decide the replication lag before choosing tools; otherwise the design looks clean but fails when database changes.
- Migration Safety: For Database Architectures: OLTP, OLAP, Replication and Scaling, decide the migration safety before choosing tools; otherwise the design looks clean but fails when architectures changes.
- Data Ownership: For Database Architectures: OLTP, OLAP, Replication and Scaling, decide the data ownership before choosing tools; otherwise the design looks clean but fails when database changes.
Distinct angle: architecture as data ownership topology
Database architecture is the topology of ownership: single primary, read replicas, partitioned primaries, event-sourced logs, analytical stores, and caches all answer different questions. The important part is deciding which component is allowed to accept writes and which components are only projections. That ownership view separates this page from a generic database overview.
Production review question
If a team adopts Database Architectures: OLTP, OLAP, Replication and Scaling, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track database-architectures health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Database Architectures: OLTP, OLAP, Replication and Scaling, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.
Further Reading
