3.1. Choosing the Right Data Store

💡 First Principle: There is no universal "best" database — only the best database for a given access pattern. Think of data stores like vehicles: a sports car excels on a highway, a pickup truck excels on a construction site, and a boat excels on water. Choosing a sports car to haul lumber fails just as spectacularly as choosing DynamoDB for complex analytical joins.

What happens when an organization puts all data in a single relational database? At small scale, it works fine. But as data grows to billions of rows and hundreds of concurrent users, the cracks appear: analytical queries slow down the transactional workload, storage costs balloon, and the database becomes the single point of failure. Without purpose-built data stores, teams end up with a system that does everything poorly instead of anything well.

The exam tests data store selection more than almost any other topic. Every scenario provides clues — access pattern (key-value lookups vs full-table scans), query type (simple reads vs complex joins), latency requirement (milliseconds vs seconds), data volume (gigabytes vs petabytes), and cost constraints. Learning to read these clues is the skill that separates passing from failing on Domain 2.