1. The problem: why can't Instagram just use "a database"?

Think about the different kinds of data a single Instagram session touches:

• Your account — username, email, password hash, privacy setting. Small, read often, must never be wrong: two people can't both own @alice.
• Follow relationships — billions of edges between users. You need "who does Alice follow?" and "who follows Alice?" quickly.
• Posts, likes and comments — hundreds of millions of new rows per day. Likes arrive in floods when something goes viral.
• Your feed and activity inbox — a constantly appended list per user, written far more often than it's read in full.
• Search — "find accounts whose name sounds like selena", which no ordinary table lookup can do.
• Photos and videos — petabytes of large immutable blobs that don't belong in a database at all (they go to object storage).

Each of these has a different shape (rows, edges, append-only logs, text), a different read/write ratio, different consistency needs, and a different scale. No single database engine is best at all of them. Picking a database is therefore not a matter of taste; it's a matter of matching the engine's strengths to each workload's access pattern. That is what this lesson teaches you to do.

2. The relational model

2.1 Tables, rows, keys and joins

The relational model (Edgar Codd, 1970) organises data into tables (formally relations). Each table has a fixed set of named, typed columns; each row is one record. Key vocabulary:

• Primary key (PK) — a column (or set of columns) that uniquely identifies a row, e.g. users.id. The database guarantees no two rows share it.
• Foreign key (FK) — a column that references another table's primary key, e.g. posts.user_id → users.id. The database can refuse a post whose user_id doesn't exist (this is called referential integrity).
• Constraint — a rule the database enforces on every write: NOT NULL, UNIQUE, CHECK (like_count >= 0).
• Schema — the declared structure of all tables. Relational databases are schema-on-write: data must match the schema when it is written. (Most NoSQL stores are closer to schema-on-read: the application interprets whatever is stored.)
• Join — combining rows from several tables at query time, e.g. "posts together with their author's username".
• SQL — the declarative query language: you describe what you want; the query planner decides how to get it (which indexes to use, which join algorithm).

2.2 Why the relational model has lasted 50+ years

• Flexible querying. Because data is normalised and SQL is declarative, you can answer questions nobody anticipated when the schema was designed ("how many users who joined in 2019 commented on a post in Brazil?").
• Strong guarantees. Constraints and transactions keep data correct even with concurrent writers and crashes.
• Mature tooling. Backups, replication, migrations, monitoring, ORMs (Instagram began life as a Django app talking to PostgreSQL through Django's ORM).

The main weakness is that a classic relational database is designed to run on one machine (plus replicas). Joins, foreign keys and multi-row transactions are cheap when all rows are on the same disk and expensive when they live on different servers. Scaling writes beyond one machine requires sharding, and sharding breaks many of those conveniences.

3. ACID, explained with concrete examples

A transaction is a group of reads and writes that the database treats as one logical unit. ACID is the set of guarantees a transactional database makes about it.

3.1 Atomicity — all or nothing

Example: when Bob likes a post, we must (1) insert a row into likes and (2) increment posts.like_count. If the server crashes between the two steps, without atomicity we'd have a like that isn't counted (or a count with no like).

BEGIN;
  INSERT INTO likes (post_id, user_id, created_at) VALUES (9001, 42, now());
  UPDATE posts SET like_count = like_count + 1 WHERE id = 9001;
COMMIT;   -- both changes become visible together, or (on error/crash) neither does

If anything fails before COMMIT — a constraint violation, a crash, an explicit ROLLBACK — the database undoes every change in the transaction. "Atomic" here means indivisible, not "concurrent-safe" (that's isolation).

3.2 Consistency — the rules always hold

Consistency means a transaction takes the database from one valid state to another, where "valid" is defined by your invariants: constraints, foreign keys, uniqueness. Examples:

• UNIQUE (username) — two concurrent sign-ups for @alice: exactly one succeeds; the other gets a unique-violation error.
• PRIMARY KEY (post_id, user_id) on likes — a double-tap that sends the request twice cannot create two likes.
• FOREIGN KEY (post_id) REFERENCES posts(id) — you can't like a post that was deleted a millisecond earlier.

3.3 Isolation — concurrent transactions don't trip over each other

Thousands of transactions run at once. Isolation means each behaves as if it were running alone. Perfect isolation (serializability) is expensive, so databases offer weaker isolation levels — the next section covers them in detail.

3.4 Durability — committed means committed

Once COMMIT returns success, the data survives a crash or power loss. Databases achieve this with a write-ahead log (WAL): before modifying data pages, the change is appended to a sequential log file and fsync-ed to disk. After a crash, the database replays the WAL to recover. In distributed systems, durability also means "written to more than one machine" — see Replication.

 Client                    Database engine                         Disk
   | COMMIT                     |                                     |
   |--------------------------> | 1. append change records to WAL     |
   |                            |------------------------------------>| wal/000123
   |                            | 2. fsync(WAL)  (data is now safe)   |
   |                            |<------------------------------------|
   | <------ "COMMIT OK" ------ |                                     |
   |                            | 3. later: flush dirty data pages    |
   |                            |    in the background (checkpoint)   |
   |                            |------------------------------------>| table files
 Crash after step 2?  →  on restart, replay WAL from last checkpoint → nothing lost.

4. Transactions and isolation levels

To understand isolation levels you first need the anomalies — the weird things that can happen when transactions interleave.

4.1 The four classic anomalies

Dirty read in Instagram terms — a moderation job reads a post that is being created and fails:

 T1 (Upload Service)                     T2 (Moderation job)
 BEGIN
 INSERT post 777 (caption "hi")
                                          SELECT * FROM posts WHERE id = 777
                                          → sees post 777   ← DIRTY: not committed!
                                          sends "new post" notification
 ROLLBACK  (media upload failed)
 → post 777 never existed, but a notification about it was already sent.

Lost update — two like requests processed by an application that does read-modify-write in code:

 T1 (like from Bob)                      T2 (like from Carol)
 SELECT like_count FROM posts WHERE id=9 → 100
                                          SELECT like_count FROM posts WHERE id=9 → 100
 UPDATE posts SET like_count = 101
 COMMIT
                                          UPDATE posts SET like_count = 101
                                          COMMIT
 Final value: 101.  Expected: 102.  Bob's like was LOST.

Non-repeatable read — a report reads Alice's follower count at the start and end of a transaction and gets 1,000 then 1,001, so its totals don't add up. Phantom — a job counts "comments on post 9 in the last hour" twice in one transaction and gets 50 then 51 because a new comment row appeared.

There's also a subtler anomaly, write skew: two transactions each read an overlapping set of rows, make a decision based on it, and write to different rows, together breaking an invariant. Classic example: "at least one admin must remain on a group" — two admins each check "there are 2 admins, so I can leave" and both leave. Only serializable isolation prevents write skew in general.

4.2 The four standard isolation levels

Read the table top to bottom as "each level adds protection and adds cost". Stronger levels either block more (locks) or abort more (optimistic engines raise a serialization failure that the application must retry).

4.3 How databases implement isolation: locks and MVCC

• Locking. A transaction takes shared locks for reads and exclusive locks for writes. Two-phase locking (2PL) — acquire locks as you go, release them only at commit — gives serializability but readers block writers and vice versa, and deadlocks become possible (the database detects cycles and aborts one victim).
• MVCC (multi-version concurrency control). Instead of overwriting a row, the database keeps multiple versions tagged with the transaction ID that created them. A reader sees the versions that were committed as of its snapshot. Readers never block writers and writers never block readers. PostgreSQL, MySQL InnoDB, Oracle and CockroachDB all use MVCC. Old versions are later cleaned up (PostgreSQL's VACUUM).

4.4 Fixing lost updates in practice

Most production apps run at read committed for performance, so you must know the targeted fixes for lost updates:

1. Atomic update in the database (best): UPDATE posts SET like_count = like_count + 1 WHERE id = 9; — the read and the write happen inside one statement under a row lock.
2. Explicit row lock: SELECT like_count FROM posts WHERE id = 9 FOR UPDATE; — the second transaction waits until the first commits.
3. Optimistic concurrency control (compare-and-set): add a version column; UPDATE posts SET caption = 'new', version = 8 WHERE id = 9 AND version = 7; — if 0 rows are affected, someone else won; re-read and retry. Great for rarely-conflicting edits like editing a caption.
4. Raise the isolation level to repeatable read (PostgreSQL) or serializable and retry on serialization failure.

5. Normalization vs denormalization

5.1 Normalization: store each fact once

Normalization organises tables so that every fact is stored in exactly one place, eliminating update anomalies (changing a fact in one place but forgetting another copy). The first three normal forms, informally:

• 1NF — every column holds a single atomic value (no comma-separated list of tags in one cell; use a separate post_tags table).
• 2NF — every non-key column depends on the whole primary key (in likes(post_id, user_id, …) don't store post_caption, which depends only on post_id).
• 3NF — non-key columns depend only on the key, not on other non-key columns (don't store author_username in posts; it depends on user_id, which lives in users).

The schema in the diagram above is normalised: a username lives only in users; to show it next to a post you join.

5.2 Denormalization: store facts where you read them

Denormalization deliberately duplicates or precomputes data to make reads cheap. Instagram-style examples:

• posts.like_count — a precomputed count instead of SELECT COUNT(*) FROM likes WHERE post_id = ? over millions of rows on every feed render.
• Storing author_username and author_avatar_url inside each feed entry so the feed can be rendered without a join to a different shard.
• Storing the same comment in comments_by_post and comments_by_user tables in Cassandra, one per query.

Rule of thumb: start normalised, denormalise specific hot read paths, and keep the denormalised copies updated asynchronously through events (e.g. a username_changed event on Kafka). Accept that a renamed user's old name may show in a few feed entries for a short while.

6. The NoSQL families

"NoSQL" ("not only SQL") isn't one technology; it's a label for databases that drop parts of the relational model — usually joins, multi-row transactions and fixed schemas — to gain horizontal scalability, high write throughput, flexible schemas or a more natural data model for a specific problem. There are six families you should know.

7. BASE: the NoSQL counterpart to ACID

Many distributed NoSQL stores describe their guarantees as BASE:

• Basically Available — the system answers requests even when some nodes or network links fail, possibly with stale data, rather than refusing.
• Soft state — the state of replicas may change over time even without new input, as background replication and repair converge them.
• Eventual consistency — if writes stop, all replicas eventually return the same value. There's no promise about when (in practice usually milliseconds).

BASE is the natural choice when you prefer availability during network partitions (the "AP" side of CAP). Example: if a like takes 500 ms to appear for a user on another continent, nobody is harmed; if Instagram refused all likes during a network blip, millions would be annoyed.

It isn't binary: Cassandra lets you choose a consistency level per query (ONE, QUORUM, ALL), and with QUORUM reads and writes you get read-your-latest-write behaviour. The maths (R + W > N) is in Replication.

8. Wide-column deep dive: Cassandra

Apache Cassandra (originally built at Facebook for inbox search, combining Amazon Dynamo's distribution with Google Bigtable's data model) is the wide-column store you are most likely to be asked about — and one Instagram has publicly described using heavily.

8.1 The data model: partition key + clustering key

A Cassandra table's PRIMARY KEY has two parts:

• Partition key (the first part, in inner parentheses) — hashed to decide which nodes store the data (via consistent hashing on a token ring). All rows sharing a partition key form one partition, stored together on the same replicas.
• Clustering key (the remaining columns) — decides the sort order of rows inside a partition. Rows are physically stored sorted by it, so range scans within a partition ("the 20 newest") are sequential and fast.

CREATE TABLE comments_by_post (
  post_id     bigint,
  comment_id  bigint,          -- time-sortable ID, newer = larger
  user_id     bigint,
  text        text,
  PRIMARY KEY ((post_id), comment_id)   -- partition key: post_id; clustering key: comment_id
) WITH CLUSTERING ORDER BY (comment_id DESC);

-- The query this table exists to serve: one partition, sequential read, newest first
SELECT comment_id, user_id, text FROM comments_by_post
 WHERE post_id = 9001 LIMIT 20;

 Token ring (hash of partition key → node)        Inside node B, partition post_id=9001
                                                  (rows sorted by clustering key DESC)
   hash(9001) = 0x7A.. ──► Node B (+ 2 replicas)   +-----------------+---------+-------------+
   hash(9002) = 0x13.. ──► Node A                  | comment_id      | user_id | text        |
   hash(9003) = 0xC4.. ──► Node D                  +-----------------+---------+-------------+
                                                   | 7012..998 (new) |   42    | "wow!"      |
                                                   | 7012..871       |   77    | "where is.."|
                                                   | 7011..003       |   15    | "first!"    |
                                                   | ... could be millions of rows ...       |
                                                   +-----------------+---------+-------------+

8.2 Query-first modelling

In SQL you model entities and figure out queries later. In Cassandra you do the opposite: list your queries first, then create one table per query, shaped so each query hits exactly one partition. The rules:

1. Every query must specify the full partition key with equality. Cassandra won't efficiently answer "comments by user 42" from comments_by_post — that would need to scan every partition on every node.
2. Range filters and ordering only on clustering columns, in their declared order.
3. No joins, so denormalise. Need comments by user too? Create comments_by_user with PRIMARY KEY ((user_id), comment_id) and write each comment to both tables (a logged batch ensures both writes eventually apply).
4. Writes are cheap, reads must be planned. Cassandra's LSM-tree storage (see Indexing & Storage Engines) appends writes sequentially, so duplicating data is the accepted price for single-partition reads.

8.3 Wide partitions and bucketing

A partition lives entirely on its replica nodes, so it can't grow forever. Guidance commonly cited for Cassandra is to keep partitions under roughly 100 MB and a few hundred thousand rows. A celebrity's activity feed or a viral post's comments can blow past that, causing slow reads, compaction pain, GC pauses and a hot partition overloading three nodes while the rest idle.

The fix is bucketing: add a component to the partition key that splits one logical entity into many physical partitions.

CREATE TABLE activity_by_user (
  user_id     bigint,
  day_bucket  int,             -- e.g. 20261023 (one partition per user per day)
  activity_id timeuuid,
  actor_id    bigint,
  type        text,            -- 'like' | 'comment' | 'follow' | 'mention'
  post_id     bigint,
  PRIMARY KEY ((user_id, day_bucket), activity_id)
) WITH CLUSTERING ORDER BY (activity_id DESC)
  AND default_time_to_live = 7776000;   -- 90 days, old activity expires automatically

Reading "latest 50 activities" now means: query today's bucket; if fewer than 50, query yesterday's, and so on. Worked example: if a celebrity receives 2 million activity events a day at ~200 bytes each, a daily bucket is ~400 MB — still too big, so you would bucket by hour (≈17 MB) or add a hash sub-bucket (user_id, day, shard 0..15). Bucket size is a deliberate design decision based on your write rate.

8.4 Other Cassandra facts worth knowing

• Writes are upserts. INSERT on an existing key overwrites it; there's no "row already exists" error. Conflicts are resolved by last-write-wins using per-cell timestamps.
• Deletes write tombstones. A delete is a marker that hides older data until compaction removes it after gc_grace_seconds. Queue-like "insert then delete" patterns create tombstone storms that make reads crawl.
• Lightweight transactions (INSERT … IF NOT EXISTS) use Paxos for compare-and-set on a single partition — about 4 round trips, so use sparingly (e.g. claiming a unique handle).
• Counters are a special column type for distributed increments, but they're not idempotent (a retried increment may double count).
• Secondary indexes and materialized views exist but are generally discouraged for high-cardinality data at scale; prefer explicit denormalised tables.
• Multi-datacenter replication is built in: NetworkTopologyStrategy with e.g. RF=3 per region.

9. SQL vs NoSQL: how to decide

10. Polyglot persistence

Polyglot persistence means using several database technologies in one system, each for the data it suits best. Each microservice owns its data store, and data is kept in sync between stores via events on the event bus or change data capture (CDC), rather than distributed transactions.

Benefits: each workload gets the right tool and scales independently; a problem in the search cluster doesn't take down sign-ups. Costs: more systems to operate, monitor, back up and secure; data is duplicated and only eventually consistent across stores; engineers must learn several modelling styles. A good principle: one store is the source of truth for each piece of data; every other copy is a derived, rebuildable view.

11. NewSQL: SQL + ACID + horizontal scale

NewSQL databases keep the relational model and serializable/strong transactions but distribute data automatically across many machines. They split tables into ranges (shards), replicate each range with a consensus protocol (Paxos or Raft), and run distributed transactions under the hood.

Trade-offs: every write must reach a consensus majority (often across zones or regions), so write latency is higher than a single-node database — tens of ms cross-region instead of ~1 ms locally. Cross-range transactions cost extra round trips. Operations and cost are higher than a single PostgreSQL. They shine when you need relational semantics and global strong consistency at a scale beyond one machine (financial ledgers, inventory, global user directories) and don't want to build sharding yourself. Instagram's PostgreSQL sharding predates mature NewSQL options; a team designing from scratch today might evaluate one for the user/relationship core.

12. Example schemas: SQL and CQL

12.1 Relational schema (PostgreSQL DDL)

CREATE TABLE users (
  id            BIGINT PRIMARY KEY,                 -- 64-bit time-sortable ID (see id-generation)
  username      VARCHAR(30)  NOT NULL UNIQUE,
  email         VARCHAR(255) NOT NULL UNIQUE,
  password_hash TEXT         NOT NULL,
  full_name     VARCHAR(100),
  bio           VARCHAR(150),
  is_private    BOOLEAN      NOT NULL DEFAULT false,
  created_at    TIMESTAMPTZ  NOT NULL DEFAULT now()
);

CREATE TABLE posts (
  id            BIGINT PRIMARY KEY,
  user_id       BIGINT NOT NULL REFERENCES users(id),
  caption       VARCHAR(2200),
  location_id   BIGINT,
  like_count    INTEGER NOT NULL DEFAULT 0 CHECK (like_count >= 0),   -- denormalized
  comment_count INTEGER NOT NULL DEFAULT 0 CHECK (comment_count >= 0),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  deleted_at    TIMESTAMPTZ                                           -- soft delete
);
CREATE INDEX posts_user_recent ON posts (user_id, created_at DESC);  -- profile grid

CREATE TABLE media (
  id            BIGINT PRIMARY KEY,
  post_id       BIGINT NOT NULL REFERENCES posts(id) ON DELETE CASCADE,
  position      SMALLINT NOT NULL,                  -- order inside a carousel
  media_type    VARCHAR(10) NOT NULL CHECK (media_type IN ('photo', 'video')),
  storage_key   TEXT NOT NULL,                      -- object-storage key, not the bytes
  width         INTEGER, height INTEGER, duration_ms INTEGER,
  UNIQUE (post_id, position)
);

CREATE TABLE likes (
  post_id       BIGINT NOT NULL REFERENCES posts(id),
  user_id       BIGINT NOT NULL REFERENCES users(id),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (post_id, user_id)                    -- one like per user per post
);
CREATE INDEX likes_by_user ON likes (user_id, created_at DESC);

CREATE TABLE comments (
  id                BIGINT PRIMARY KEY,
  post_id           BIGINT NOT NULL REFERENCES posts(id),
  user_id           BIGINT NOT NULL REFERENCES users(id),
  parent_comment_id BIGINT REFERENCES comments(id), -- replies
  text              VARCHAR(2200) NOT NULL,
  created_at        TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX comments_by_post ON comments (post_id, created_at DESC);

CREATE TABLE follows (
  follower_id   BIGINT NOT NULL REFERENCES users(id),
  followee_id   BIGINT NOT NULL REFERENCES users(id),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (follower_id, followee_id),           -- "whom do I follow?"
  CHECK (follower_id <> followee_id)
);
CREATE INDEX follows_reverse ON follows (followee_id, follower_id);  -- "who follows me?"

A typical relational query — the 12 most recent posts for a profile grid, with a cover image each:

SELECT p.id, p.like_count, m.storage_key
  FROM posts p
  JOIN media m ON m.post_id = p.id AND m.position = 0
 WHERE p.user_id = 42 AND p.deleted_at IS NULL
 ORDER BY p.created_at DESC
 LIMIT 12;

12.2 Wide-column schema (Cassandra CQL), one table per query

-- Q1: a user's posts, newest first (profile grid)
CREATE TABLE posts_by_user (
  user_id     bigint,
  post_id     bigint,                     -- time-sortable, so DESC = newest first
  caption     text,
  media_keys  list<text>,
  created_at  timestamp,
  PRIMARY KEY ((user_id), post_id)
) WITH CLUSTERING ORDER BY (post_id DESC);

-- Q2: fetch one post by id (e.g. from a feed entry or a shared link)
CREATE TABLE posts_by_id (
  post_id     bigint PRIMARY KEY,
  user_id     bigint,
  caption     text,
  media_keys  list<text>,
  created_at  timestamp
);

-- Q3: who liked a post? / did user X like post P?  (single partition, clustering lookup)
CREATE TABLE likes_by_post (
  post_id     bigint,
  user_id     bigint,
  liked_at    timestamp,
  PRIMARY KEY ((post_id), user_id)
);

-- Q4: counts shown under each post
CREATE TABLE post_counters (
  post_id        bigint PRIMARY KEY,
  like_count     counter,
  comment_count  counter
);

-- Q5: comments on a post, newest first
CREATE TABLE comments_by_post (
  post_id     bigint,
  comment_id  bigint,
  user_id     bigint,
  text        text,
  PRIMARY KEY ((post_id), comment_id)
) WITH CLUSTERING ORDER BY (comment_id DESC);

-- Q6 / Q7: following and followers lists (the same edge written twice)
CREATE TABLE following_by_user (
  user_id      bigint,  followee_id bigint,  since timestamp,
  PRIMARY KEY ((user_id), followee_id)
);
CREATE TABLE followers_by_user (
  user_id      bigint,  follower_id bigint,  since timestamp,
  PRIMARY KEY ((user_id), follower_id)
);

-- Q8: a user's home-feed timeline (post IDs pushed by fan-out workers), bucketed by month
CREATE TABLE feed_by_user (
  user_id     bigint,
  month       int,                         -- e.g. 202610
  post_id     bigint,
  author_id   bigint,
  PRIMARY KEY ((user_id, month), post_id)
) WITH CLUSTERING ORDER BY (post_id DESC)
  AND default_time_to_live = 2592000;      -- keep 30 days of timeline

Notice the differences from the SQL version: there are no foreign keys, no joins, the follow edge is written twice, posts are written twice, and counters live in their own table. Every table is designed around exactly one query, and every query hits exactly one partition.

13. How Instagram uses databases

In this course's reference architecture, that becomes:

Rough numbers (assumptions)

Assume 500M daily active users; 100M new posts/day; each post gets an average of 40 likes and 2 comments; each active user generates 10 likes/day.

Likes:     500M × 10           = 5 B likes/day  ≈ 58,000 writes/s average, ~150,000/s peak
Posts:     100M / 86,400       ≈ 1,160 posts/s
Feed fan-out: 1,160 posts/s × ~200 followers each ≈ 232,000 timeline inserts/s
Users table: 2 B rows × ~1 KB  ≈ 2 TB  → fits a few dozen PostgreSQL shards comfortably
Likes rows: 5 B/day × ~40 B    ≈ 200 GB/day ≈ 73 TB/year → wide-column territory

The numbers tell the story: the user table is "small" and correctness-critical (SQL); likes and timelines are enormous and append-heavy (NoSQL). See Back-of-the-Envelope Estimation.

14. Trade-offs & common pitfalls

Common pitfalls

• Choosing NoSQL "for scale" at small scale. A single well-tuned PostgreSQL with replicas handles tens of thousands of transactions per second. Premature NoSQL costs you transactions and flexibility for nothing.
• Modelling Cassandra like SQL — normalised tables, then discovering you need ALLOW FILTERING (a full-cluster scan) for every real query.
• Unbounded partitions — partitioning by post_id alone for likes on a post that gets 50M likes. Bucket it.
• Read-modify-write in application code at read committed → lost updates. Use atomic updates, SELECT … FOR UPDATE or version checks.
• Assuming the default isolation is serializable. It almost never is (PostgreSQL: read committed; MySQL: repeatable read).
• Long transactions holding locks or old MVCC snapshots → lock waits, table bloat, replication lag.
• Storing blobs in the database. Images belong in object storage; store only the key.
• Dual writes without a plan — writing to PostgreSQL and Elasticsearch from the app, one fails, they diverge forever. Use events/CDC from a single source of truth.
• Queue-like tables in Cassandra (insert, process, delete) → tombstone accumulation and slow reads.

15. Real-world technologies

16. Interview corner

17. Check your understanding

Related lessons

• Database Indexing & Storage Engines — B-trees vs LSM-trees: why SQL reads and Cassandra writes are fast
• Replication — read replicas, quorums (R + W > N) and durability across machines
• Sharding — how Instagram splits PostgreSQL into thousands of logical shards
• Consistent Hashing — how Cassandra maps partition keys to nodes
• CAP Theorem & Consistency Models — the theory behind ACID vs BASE
• Unique ID Generation — Instagram's 64-bit time-sortable IDs used as clustering keys
• Caching — Redis in front of the databases for hot reads
• Likes, Comments & Counters — handling hot counters without lost updates