Normalisation

Store each fact once and link it by keys, which avoids inconsistent copies. Reads then need joins, which is why read-heavy systems sometimes denormalise on purpose.

Where it shows up in real systems

  • Relational database

    The primary handles every write; read replicas add read capacity but lag slightly behind, so a user may not see their own write. A Multi-AZ standby takes over in about a minute if the primary fails. Sharding multiplies write capacity, but a bad shard key creates a hot shard. Without connection pooling, many app instances exhaust the connection limit.

    In production: PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox