What Is Database Engineering?
Mental Model
A database is not a black box that stores data. It is a sophisticated software system with storage engines, concurrency models, query planners, replication topologies, and failure modes that directly determine the reliability and performance of everything built on top of it.
Most backend engineers are database consumers: they write SQL, use an ORM, and treat the database as a reliable service. Database engineers go deeper: they understand why a query plan chooses a full table scan, how InnoDB's MVCC enables non-blocking reads, and when to choose eventual consistency over strong consistency for a specific data pattern.
This curriculum teaches you to make that transition.
Who This Track Is For
This track is designed for engineers who:
- Write backend code that talks to databases daily
- Have used at least one database in production (MySQL, PostgreSQL, MongoDB, etc.)
- Want to move from "it works" to "I understand why it works and what will break it"
- Are preparing for staff engineer interviews where database architecture is expected knowledge
You do NOT need to be a DBA. This is an engineering track, not an operations track. The focus is on making better architecture decisions, not managing database clusters day-to-day.
The Learning Path
Phase 1: Storage Internals (The Foundation)
Before you can reason about scaling databases, you need to understand how they store and retrieve data. These modules explain the machinery:
→ Storage Engines: B-Trees vs LSM-Trees
Why InnoDB uses B-Trees (reads) and Cassandra uses LSM-Trees (writes)
→ Write-Ahead Logging (WAL)
How databases achieve durability without fsyncing every write
→ InnoDB Architecture Deep Dive
Buffer pool, page cache, row formats, and clustered indexes
→ Database Indexing Deep Dive
B-Tree indexes, composite indexes, covering indexes, and index maintenance cost
→ Database Connection Pool Tuning
HikariCP, pool sizing mathematics, and connection lifecycle management
Why start here: Every performance problem, every scaling decision, and every consistency trade-off traces back to the storage engine. Understanding the storage layer gives you a mental model that makes everything else obvious.
Phase 2: Consistency and Concurrency (The Theory)
Modern databases make explicit trade-offs around consistency, isolation, and performance. This phase teaches you to reason about those trade-offs:
→ Database Concurrency: Optimistic vs Pessimistic Locking
MVCC, row locks, table locks, and when each is appropriate
→ Distributed Transactions: Death of ACID (Part 1–7 series)
2PC, Saga pattern, transactional outbox, idempotency, event sourcing
→ CAP Theorem and PACELC
What these theorems actually mean for system design decisions
→ Linearizability vs Sequential Consistency
The consistency spectrum and where popular databases fall on it
Phase 3: Scaling Primitives (The Application)
With the foundation in place, these modules cover the standard toolkit for scaling beyond a single database:
→ Database Sharding Part 1–7 (series)
Vertical ceiling → partitioning → consistent hashing → cross-shard queries → zero-downtime migration
→ Consistent Hashing in Distributed Systems
The algorithm behind DynamoDB, Cassandra, and Redis Cluster's partitioning
→ Replication and High Availability
Primary-replica, multi-leader, and conflict resolution
→ Database Scaling: 100 Million Users
A practical walkthrough of a real scaling journey
Phase 4: Specialized Storage Systems (The Breadth)
Beyond relational databases, this phase covers the major specialized storage systems and when to use each:
→ Redis: Beyond Cache (comprehensive guide)
Data structures, persistence, Lua scripting, cluster mode
→ Cassandra Internals, Data Modeling, Multi-Region
LSM-trees, gossip protocol, and CQL data modeling patterns
→ DynamoDB: Single-Table Design and Advanced Patterns
Access pattern-first design and the NoSQL mental model shift
→ MongoDB Internals: WiredTiger and Aggregation Optimization
Document model trade-offs and production pitfalls
→ Elasticsearch: Deep Dive and Query Optimization
Inverted indexes, relevance scoring, and production operations
→ Time-Series Databases
InfluxDB, Prometheus, and purpose-built storage for metrics
Phase 5: Production Operations (The Craft)
The final phase covers operating databases in production — what goes wrong and how to recover:
→ PostgreSQL MVCC, Vacuum, and Locking Playbook
→ MySQL/PostgreSQL Performance Tuning
→ Zero-Downtime Database Migrations (expand-contract pattern)
→ Chaos Engineering for Data Infrastructure
→ Distributed Data Observability: Key Metrics
How to Use This Curriculum
Option 1: Sequential Learning (Recommended for Most Engineers)
Work through the modules in order within each phase. The dependency graph matters — sharding makes much more sense after you understand storage engines and replication.
Estimated time: 4–6 hours per module, 8–12 modules per phase = ~3 months of focused learning at 1 module/week.
Option 2: Topic-Driven Learning
If you have a specific upcoming project or interview, jump to the relevant module. The modules are designed to be independently useful, even if some context is missing.
For a senior backend engineering interview: Start with CAP/PACELC → Database Indexing → Sharding series → Redis → Cassandra.
For a staff/principal interview: Add Distributed Transactions series + Linearizability + Consistent Hashing + one deep-dive case study (Discord or Stripe).
Option 3: Architecture Review Mode
Use the production operations modules when you have a specific database problem. The modules include diagnostic commands, monitoring queries, and incident playbook steps.
What You Will Be Able to Do
By the end of this track, you will be able to:
System Design
- Choose the right database for a given access pattern with clear reasoning
- Design a sharding strategy for a system expecting 10× growth
- Explain CAP/PACELC trade-offs in terms of business impact, not just theory
- Architect a multi-region database setup with specific consistency guarantees
Production Engineering
- Diagnose slow queries using EXPLAIN and query plan analysis
- Identify and resolve deadlocks without causing additional downtime
- Design a schema migration strategy that works without a maintenance window
- Calculate optimal connection pool sizes based on hardware and workload
Interviews
- Answer "How would you design a system that handles 1 million requests/day?" with database depth
- Explain InnoDB's MVCC and how it enables non-blocking reads
- Discuss the trade-offs between Cassandra, DynamoDB, and PostgreSQL for a specific use case
- Walk through a real distributed transaction problem and explain the Saga pattern solution
Prerequisites Check
Before starting, make sure you have:
- Used SQL to write queries with JOINs, GROUP BY, and aggregate functions
- Built at least one application that reads and writes to a database
- A basic understanding of indexing (you know indexes make queries faster, even if you don't know exactly why)
- Familiarity with the CAP theorem at a surface level (you've heard of it, even if the details are fuzzy)
If you're missing any of these, spend 1–2 hours on the MySQL Mastery Roadmap first — it covers the SQL fundamentals you'll need.
Start Here
The first module in the track is Storage Engines: B-Trees vs LSM-Trees. It is the foundation for everything that follows.
→ Storage Engines: B-Trees vs LSM-Trees
Alternatively, if you are already comfortable with storage internals and want to dive into scaling:
→ Database Sharding Part 1: The Vertical Ceiling
Key Takeaways
- Database engineering is not about memorizing SQL syntax — it is about understanding storage models, consistency guarantees, and data access patterns.
- The learning path moves from storage internals → scaling primitives → distributed systems → production operations.
- Start with the storage engine modules before sharding — you cannot make good sharding decisions without understanding what you are distributing.