TAO: The power of the graph

Ideas you will meet

Caching

Cache-aside, write-through, eviction and invalidation strategies.

Databases

Schemas, indexes, query plans and choosing a store.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• System Design Foundations · 14 minPutting it together: design a URL shortenerA complete worked design using everything so far: requirements, estimates, data model, key generation, caching, scaling and failure handling.Read hereClose

  This lesson uses every earlier idea on one concrete problem. Read it as a model of how to talk through a design.

  1. Clarify requirements

  Functional

  • Given a long URL, create a short one (sho.rt/Ab3dE9).
  • Opening the short URL redirects to the long one.
  • Optional custom alias and expiry (we will add these later).

  Non-functional

  • Redirects are fast (under about 100 ms) and highly available. If redirects fail, every link on the internet that points to us is broken.
  • Short keys must be unique. Links must not disappear unexpectedly.
  • Keys should not be guessable in sequence (so people cannot enumerate every link).

  Out of scope for now: user accounts, detailed analytics.

  2. Estimate

  Using the numbers from lesson 3: 100 million new links a month is about 40 writes per second. With reads at 10 times writes, about 400 reads per second, peaking maybe at 2,000. Five years of data is about 6 billion records at roughly 500 bytes each, so around 3 TB.

  Conclusion: traffic is modest and data is small enough for a single replicated relational database for a long time. The design should be simple, with the focus on the read path.

  3. High-level design

  100%

  Figure SDA-FND-12-1 · URL shortener architecture · © forcsguy.com

  Create a link (write path)

  1. Client sends POST /links with the long URL.
  2. The server obtains a unique ID and encodes it into a short key.
  3. It stores (key, long_url, created_at, expires_at) in the database.
  4. It returns the short URL.

  Open a link (read path)

  1. Client requests GET /Ab3dE9.
  2. The server looks in the cache. On a hit it returns the redirect.
  3. On a miss it reads the database, fills the cache, then redirects.

  4. The interesting parts

  Generating short keys

  Use base62 (a-z, A-Z, 0-9). Seven characters give 62^7, about 3.5 trillion keys, far more than the 6 billion we need.

  Options for producing a unique key:

  Approach	Good	Bad
  Hash the URL and take 7 characters	stateless	collisions, same URL gives same key
  Random key, check the database	simple	needs a check and retry, extra write load
  Unique ID, then base62	no collisions by construction	needs an ID generator, and sequential IDs are guessable

  A good choice: obtain IDs from a generator (a counter handed out in ranges to each server, or a Snowflake-style 64-bit ID), then base62-encode. To stop people guessing the next link, scramble the ID with a reversible function before encoding.

  100%

  Figure SDA-FND-12-2 · Two ways to make a short key · © forcsguy.com

  How base-62 conversion works: divide the number by 62 repeatedly and read the remainders from the last to the first. The number 11157 gives remainders 59, 55 and 2, and those map to the symbols X, T and 2, so the key is 2TX. With seven positions there are 62^7, about 3.5 trillion, possible keys.

  The database

  One table is enough:

  Column	Notes
  key (primary key)	the short code
  long_url	the target
  created_at, expires_at	for expiry

  Lookup is always by key, so the primary key index serves every read. A relational database works; a key-value store would too. Start with the one you can operate.

  The read path and the cache

  The same few links are opened over and over. A cache such as Redis in front of the database absorbs most reads. With cache-aside and a TTL of a day, plus LRU eviction, the hit rate is typically very high. Redirect responses are tiny, so the cache is small.

  A 301 redirect (permanent) can be cached by browsers, reducing traffic but hiding repeat clicks from analytics. A 302 (temporary) keeps every click visible. Choose based on whether you need accurate click counts.

  The two flows end to end

  100%

  Figure SDA-FND-12-3 · Creating a short link · © forcsguy.com

  100%

  Figure SDA-FND-12-4 · Following a short link · © forcsguy.com

  5. Scale and failure

  • Application servers are stateless, so add more behind the balancer (lesson 2).
  • Database reads: add read replicas if the cache is not enough. Writes are only about 40 per second, so sharding is unnecessary. If it ever becomes necessary, shard by key hash (lesson 5).
  • Cache failure: the database must survive a cold cache. Warm it, or ramp traffic back gradually.
  • Database failure: replicas with automatic failover, backups tested by restoring.
  • Abuse: rate limit link creation per client, and check submitted URLs for malware, since shorteners are popular with spammers.
  • Unknown keys: return 404 and cache the miss briefly, so repeated lookups of missing keys do not reach the database (lesson 6).

  6. What would you change at 100 times the size?

  Trace the bottleneck honestly: first the cache and replica count, then the ID generator becoming a coordination point, then the database size. At that point you would shard by key hash, use a multi-region deployment with a global key space, and move click counting fully onto an event stream (lesson 8).

  Worked numbers, end to end

  Assume 100 million new short links a month and a read to write ratio of 100 to 1.

  • Writes: 100,000,000 / (30 x 86,400) = about 40 per second on average, perhaps 120 at peak.
  • Reads: 40 x 100 = 4,000 per second on average, 12,000 at peak.
  • Storage: about 500 bytes per record (long URL, short key, dates, owner). Over 5 years: 100M x 12 x 5 = 6 billion links x 500 bytes = 3 TB. That fits on a handful of database nodes, so the data size is not the hard part.
  • Key length: with base 62 (a to z, A to Z, 0 to 9), 7 characters give 62^7 = about 3.5 trillion keys, comfortably more than the 6 billion we need, with room to spare against guessing.
  • Cache: if 20% of links get 80% of reads, caching the hottest 20% of one day's reads needs roughly 4,000 x 86,400 x 0.2 x 500 bytes = about 35 GB, which one or two cache nodes hold.

  So the real engineering problems are not size. They are generating unique keys without collisions at scale, keeping redirects fast, and not going down when one link goes viral.

  100%

  Figure SDA-FND-12-5 · Capacity numbers for the shortener · © forcsguy.com

  Redirect: 301 or 302?

  A short link answers with a redirect. 301 (permanent) lets browsers and intermediaries cache the redirect, which cuts load on your servers but means you never see the later clicks, so click analytics become inaccurate, and you cannot change the destination for people who cached it. 302 (temporary) is not cached, so every click reaches you: more traffic, but accurate analytics and the ability to change or disable a link immediately. Products that sell analytics, or must be able to remove abusive links, use 302 (or 307). Mention the trade-off in an interview; it shows you think about product consequences.

  Handling a link that goes viral

  One link suddenly gets 50,000 requests per second. Everything funnels onto one key: one cache node, one database row. Defences, in order of cost:

  1. Cache the redirect in a CDN with a short TTL (say 60 seconds). Most of those requests never reach you.
  2. Replicate hot keys across several cache nodes, or keep a tiny in-memory cache on each app server for the hottest few hundred keys.
  3. Rate limit per client so a script cannot add to the storm.
  4. Degrade gracefully: if the database is struggling, serve from cache even past TTL.

  100%

  Figure SDA-FND-12-6 · Layers of defence for a viral link · © forcsguy.com

  Mistakes people make

  • Guessable keys. Sequential ids let anyone enumerate every link. Use random or encoded ids if links may be private.
  • Collisions from hashing the URL. Truncating a hash of the long URL will eventually collide. Detect and retry, or generate keys from a counter or a pre-generated pool.
  • Forgetting abuse. Short links hide destinations, so they are used for phishing. Check destinations against blocklists and let people report links.
  • A single counter as a single point of failure. If one service hands out every id, it needs replicas or ranges handed to each app server in blocks.
  • Ignoring expiry and cleanup. Decide what happens to unused or expired links; otherwise storage and the key space fill with dead entries.

  Try it yourself

  Use the System Builder challenges "The database becomes the bottleneck" and "A viral link", which follow this shortener's growth. Then build the Snowflake ID lab and think about whether a time-based id is suitable for short keys. To build your own, open the URL shortener on the free canvas.

  More on this site

  Related reading

  • MongoDB: Shard KeysMongoDB · MongoDB Inc.Documentation
  • Consistent Hashing and Random Trees (paper)Karger et al. · MITPapers
  • TAO: Facebook's Distributed Data Store for the Social Graph (paper)Bronson et al. · Meta (Facebook)Papers
  • Hello Interview: System Design in a HurryHello InterviewCourses

  Show 6 moreShow fewer

  • Hello Interview: System Design WalkthroughsEvan King & Stefan Mai · Hello InterviewYouTube
  • The System Design PrimerDonne Martin · donnemartinGitHub
  • TAO: The power of the graphMeta Engineering · MetaCase Studies
  • Megastore: Providing Scalable, Highly Available Storage (paper)Baker et al. · GooglePapers
  • Sharding MySQL at TwilioTwilio engineers · TwilioCase Studies
  • Sharding out Elasticsearch at VintedVinted engineers · VintedCase Studies

  Open this lesson with its quiz and exercise

• Databases Deep Dive · 12 minReplication topologies and multi-region databasesSingle-leader, multi-leader and leaderless replication, how they handle conflicts and lag, and what changes across regions.Read hereClose

  Why replicate

  Replication keeps copies of data on several machines for three reasons: availability (survive a node failure), read scaling (serve reads from replicas) and latency (put data near users). The hard part is keeping copies consistent while writes continue. (Basics are in the replication and sharding lesson of the foundations course; this lesson compares the topologies.)

  Single-leader (primary and replicas)

  One node, the leader (primary or master), accepts writes and ships its changes to followers (replicas), which serve reads.

  100%

  Figure SDA-DDV-04-1 · Single-leader replication · © forcsguy.com

  • Synchronous replication waits for a follower before acknowledging: safer, slower, and a stalled follower can block writes. Asynchronous is faster but a failover can lose the latest writes. A common compromise: one synchronous follower, others asynchronous.
  • Failover must detect failure, choose the most up-to-date replica, redirect clients and ensure the old leader does not come back believing it still leads (split brain).
  • Replication lag causes stale reads. Techniques: read-your-writes (route a user's reads to the leader shortly after they write), monotonic reads (keep a user on one replica), and checking replica position.

  Multi-leader

  Several nodes accept writes (often one per region) and replicate to each other. Benefits: local write latency and continued operation if a region is cut off. Cost: write conflicts.

  Conflict handling options:

  • Avoid them: route all writes for one record to one leader (for example by user or region).
  • Last write wins by timestamp: simple, but silently drops one of two concurrent updates and depends on clocks.
  • Merge values (union of sets, counters) using mergeable data types (CRDTs; see the collaborative editing lesson).
  • Custom resolution in application code, or ask the user.

  Multi-leader also appears in offline-capable apps (each device is a leader) and collaborative editing.

  Before: single leader

  100%

  After: multi-leader across regions

  100%

  What changed

  • Users in each region write to a nearby database
  • Concurrent edits to the same row need conflict handling
  • More moving parts to run and monitor

  Leaderless (Dynamo-style)

  Any replica accepts writes; clients write to several replicas and read from several, using quorums (W + R > N) to get fresh data (see the key-value store lesson). Background anti-entropy and read repair fix stale copies; versions or vector clocks detect conflicts. It favours availability and is typical of Cassandra and DynamoDB-style stores.

  100%

  Figure SDA-DDV-04-2 · Choosing a replication model · © forcsguy.com

  Multi-region designs

  • Active-passive: one region serves writes; another is a warm standby. Simple; failover loses a little data (the replication lag) and takes minutes.
  • Active-active: several regions serve traffic. Requires either partitioning data by home region (each record has one home, cross-region reads are replicas) or true multi-leader conflict handling.
  • Global databases use consensus across regions (see the consensus lesson) for strong consistency at the cost of cross-region write latency; some offer tunable consistency per query.
  • Latency numbers matter: a cross-ocean round trip is around 100 ms or more, so synchronous cross-region replication adds that to every write.
  • Data residency laws may require keeping certain users' data in a region.

  Partitioning and replication together

  Real systems shard data into partitions and replicate each partition (a leader per partition spreads write load across nodes). Rebalancing, hot partitions and cross-partition transactions are the new problems (see sharding and the consistent-hashing lesson).

  Master/slave naming

  You will see "master/slave", "primary/replica" and "leader/follower" for the same single-leader idea; most current documentation prefers the last two.

  Checklist

  • What happens to writes if the leader or a region is lost, and how long?
  • How much data can we lose (RPO) and how long can we be down (RTO)?
  • How do we handle stale reads from replicas?
  • Who resolves conflicts, and how?
  • Have we practised failover?

  Real-world reading

  Related reading

  • Active-Active for Multi-Regional ResiliencyNetflix Engineering · NetflixCase Studies
  • Designing Data-Intensive ApplicationsMartin Kleppmann · O'ReillyBooks
  • Read Consistency with Database Replicas at ShopifyShopify engineers · ShopifyCase Studies
  • Uber Schemaless: A Scalable MySQL DatastoreUber Engineering · UberCase Studies

  Show 6 moreShow fewer

  • Mitigating MySQL Replication Lag and Reducing Read Load at GithubGithub engineers · GithubCase Studies
  • Cassandra architecture overviewApache Cassandra · Apache Software FoundationDocumentation
  • How Discord Stores Trillions of MessagesBo Ingram · DiscordBlogs
  • Spanner: Google's Globally Distributed Database (paper)Corbett et al. · GooglePapers
  • Scaling Multitenant Architecture Across Multiple Data Centres at Shopify - Weingarten, Engineering Lead at ShopifyShopifyYouTube
  • MIT 6.824: Distributed SystemsRobert Morris · MITCourses

  Open this lesson with its quiz and exercise

• Databases Deep Dive · 13 minChoosing a database typeA practical map from workload to database: relational, document, key-value, wide-column, search, graph, time-series and vector stores.Read hereClose

  Start from the access pattern

  There is no best database; there is a best database for a workload. Ask:

  1. What are the main queries (by key, by range, by search, by relationship)?
  2. How much data and how fast does it grow? Read/write ratio?
  3. What consistency and transaction guarantees are needed?
  4. What latency is required, and where are users?
  5. What can your team operate?

  The families

  100%

  Figure SDA-DDV-05-1 · Map from need to database family · © forcsguy.com

  Relational (PostgreSQL, MySQL)

  Tables, SQL, joins, constraints, ACID transactions. The default for most business data. PostgreSQL has rich features (JSON, full-text, extensions, many index types); MySQL is widely deployed and simple to operate. They scale vertically very far, and read replicas and sharding extend them. Choose when data is structured, relationships matter and correctness is critical.

  Document (MongoDB and similar)

  Stores JSON-like documents; flexible schema; related data can be embedded in one document so a single read gets everything. Good for content, catalogues and objects read whole. Watch for duplicated data, joins you must do in code, and weaker multi-document transaction habits.

  Key-value (Redis, Memcached; DynamoDB as a key-value/wide hybrid)

  Lookup by key at very low latency. Redis adds data structures (hashes, sorted sets, lists, bitmaps), persistence and clustering (see the Redis lesson). Ideal for caches, sessions, counters, rate limits, leaderboards. Not for ad-hoc queries.

  Wide-column and partitioned key stores (Cassandra, DynamoDB, HBase)

  Data is partitioned by a partition key across many nodes; you design tables around queries. Excellent write throughput, horizontal scale and availability. Cost: limited query flexibility, careful key design (hot partitions), eventual consistency by default. Good for event logs, messaging history, time-ordered user data.

  Search engines (Elasticsearch, OpenSearch, Solr)

  Build an inverted index (word to documents) for full-text search, relevance scoring, filters and facets. Usually a secondary copy of data from a primary database, kept in sync. Not a system of record: treat it as a derived index that can be rebuilt.

  Graph (Neo4j and others)

  Stores nodes and relationships and answers questions that follow connections: friends of friends, fraud rings, recommendations, dependency analysis. Where many-hop traversals would need expensive recursive joins in SQL, a graph database is natural.

  Time-series (InfluxDB, TimescaleDB, Prometheus)

  Optimised for append-heavy, timestamped data with time-range queries, downsampling and retention. Used for metrics, IoT and finance ticks (see the metrics monitoring lesson). Keep tag cardinality low.

  Vector databases (and vector indexes in other databases)

  Store embeddings (arrays of numbers representing meaning) and find the nearest neighbours, using approximate indexes (graph-based or clustering) for speed. Used for semantic search and retrieval for AI applications. Many general databases now offer vector indexes, which can be enough for moderate scale and avoids another system.

  A quick chooser

  Need	First choice
  Business data with relationships and transactions	Relational
  Flexible, self-contained records	Document
  Cache, session, counter, leaderboard	Redis
  Massive write volume, simple access by key	Wide-column / DynamoDB-style
  Full-text search and facets	Search engine
  Many-hop relationship queries	Graph
  Metrics and sensor data	Time-series
  Semantic similarity	Vector index
  Analytics on large history	Warehouse or lakehouse (see the big data course)

  Polyglot persistence and its price

  Many systems use several stores, each for what it does best: a relational database as the source of truth, a cache, a search index and a metrics store fed from it. The cost is keeping them in sync (change events, outbox pattern, rebuild jobs), more to operate and more failure modes. Add a store only when a measured need justifies it.

  SQL versus NoSQL, honestly

  "NoSQL" is a family of different designs, not one thing. Relational databases scale further than many assume; NoSQL stores often give up joins and some consistency for scale and flexibility. Decide on requirements, not fashion. If in doubt, start relational and specialise later.

  Questions before committing

  • Can we model our top ten queries easily?
  • What happens at 10 times the data? At a regional failure?
  • How do we back up, restore, migrate and monitor it?
  • Does the team know it, and is it supported well on our platform?

  Real-world reading

  Related reading

  • Redis UniversityRedis · Redis Ltd.Courses
  • RedisRedis · Redis Ltd.GitHub
  • Redis DocumentationRedis · Redis Ltd.Documentation
  • Build Your Own XCodeCrafters · GitHubGitHub

  Show 6 moreShow fewer

  • Redis persistenceRedis · Redis Ltd.Documentation
  • Moving Food Feed from Redis to Cassandra at ZomatoZomato engineers · ZomatoCase Studies
  • Scale with Redis ClusterRedis · Redis Ltd.Documentation
  • Improving key expiration in Redis at TwitterTwitter engineers · TwitterCase Studies
  • Migrating MySQL from 5.6 to 8.0 at FacebookFacebook engineers · FacebookCase Studies
  • Decreasing RAM Usage by 40% Using jemalloc with Python & Celery at ZapierZapier engineers · ZapierCase Studies

  Open this lesson with its quiz and exercise