Figma: Scaling Postgres 100× and Real-Time Multiplayer

This page is one interview loop in three rounds, built on a real company's public engineering history. All three rounds design the same product: Figma, a design tool where many people edit one file at the same time in a browser. Behind it sit two very different systems. One keeps each open file in memory and merges everyone's edits in real time. The other is a relational database that remembers who owns what: files, teams, permissions, comments. Each round is an era of that second system, and each era ended because the one before it ran out of room.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: Why Figma?

A Live Whiteboard Backed by a Filing Cabinet

Picture a whiteboard that ten people draw on at once, from different countries, and a filing cabinet in the corner that remembers who owns each whiteboard, who may see it, and every comment pinned to it.

• The whiteboard is live. Every drag and every keystroke must show up for everyone, right away. Figma's clients "send updates every 33ms (30 FPS)" while someone edits (2022).
• The filing cabinet is relational. Files belong to projects, projects to teams, teams to organizations; permissions cut across all of them. That's what SQL, joins and transactions are good at.
• The filing cabinet had to grow about a hundredfold. Figma wrote in 2024 that its database stack "has grown almost 100x since 2020", and it did that without closing the office: no maintenance windows.

Figma kept these two jobs in two different engines, and never let the second one sit on the first one's hot path.

Synthesizing vector architecture diagram...

Read it as two tracks. The multiplayer engine changed its implementation (TypeScript, then Rust) and its durability (checkpoints, then a journal). The metadata database changed its shape three times: one instance, then a dozen by table group, then tables split across many.

A few words we'll use all page:

What Makes It Hard

• Two workloads with nothing in common. Editing is a stream of tiny updates per file, latency-critical and fine in memory. Metadata is relational, needs transactions, and must be durable before the user sees "saved".
• Migrations under live traffic. Every scaling step moves live data between databases while thousands of application servers keep querying it.
• Keeping the product's queries working. Once data is split, joins, foreign keys and transactions across the split stop working, and the application was written assuming they do.

The Question the Whole Loop Answers

How do we keep real-time editing instant and scale a single relational database far beyond one machine, step by step, without downtime?

The answer grows every round:

• Round 1: keep the database off the keystroke path. A multiplayer server per file holds it in memory and orders edits; Postgres holds metadata, helped by a bigger machine, read replicas and PgBouncer.
• Round 2: when one machine isn't enough, move groups of tables to their own databases, using logical replication, a pause of seconds and a way back.
• Round 3: when single tables outgrow a database, shard them: colos, logical sharding through views before any data moves, a query-routing proxy, and physical splits that fence the old copy for good.

---

Round 1 · Mid-level · "Era 1: Multiplayer Servers and One Big Postgres"

~35 min · SDE II (L5) · about 2016–2020 · one RDS Postgres instance (published) · 60,000 queries/s and ~10,000 row writes/s at the peak (planning figures) · edits feel instant and the database keeps up

R1.1 Establish Design Scope

The interviewer sets the scene: "We're building a design tool that runs in the browser. Several people can have the same file open and edit it together, live. We also have the usual product data: users, teams, projects, files, permissions, comments. Design the backend."

Out of scope for this round: splitting the database, cross-region failover, plugins, rendering.

R1.2 Functional Requirements, Derived Step by Step

Not yet: partitioning the database, sharding, a journal of every change (Figma described one in 2022; we meet it in R1.9).

R1.3 Non-Functional Requirements: the Questions

We name each quality first; the numbers come in R1.7.

• Edit latency. Your own change: immediate (applied locally). Everyone else's: one round trip plus server processing. A slow operation on one file must not stall other files.
• Convergence. When edits stop, every client must show exactly the same file. Figma (2019): "we cannot allow two clients editing the same Figma document to diverge and never converge again."
• Edit durability. How much work can a server crash lose? In this era: up to one checkpoint interval.
• Metadata consistency. Permissions, ownership and billing need transactions. Some reads must see the user's own write immediately (read-your-writes).
• Database headroom. The one primary must stay well below saturation. Figma (2023): "If our database became completely saturated, Figma would stop working."

R1.4 The API

Figma hasn't published its multiplayer wire format. The messages below are illustrative: their fields come from mechanisms Figma did publish (property-level changes, client-generated object IDs, one parent-and-position property, server ordering and rejection), and the names are ours.

Client → server: changes (sent at most every 33 ms while the user edits)

Server → client: ack, broadcast, reject

The parent property. An object's place in the tree is one property, parent, whose value is {parent_id, position}. The position is a fractional index: a number between 0 and 1 that sorts siblings. Figma (2019): "the parent link and this position must both be stored as a single property so they update atomically."

Metadata: create a file (an illustrative internal endpoint; Figma's public REST API is not this)

httpCopy
POST /v1/files HTTP/1.1
Authorization: Bearer <session token>
Idempotency-Key: 5d2f8c1e-9a4b-4e7f-b1c3-2a6d9e0f7b18
Content-Type: application/json

{ "team_id": "8812", "project_id": "40251", "name": "Checkout redesign" }

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{ "file_key": "fk_7Qm2xR", "name": "Checkout redesign", "project_id": "40251", "created_at": "2020-03-02T17:04:11Z" }

Retries are safe because the guard comes first. Creating a file also writes an empty first checkpoint to S3, an external call. The server claims the idempotency key before that call, in the same transaction that creates the file row, with an insert that does nothing if the key already exists:

sqlCopy
BEGIN;
INSERT INTO idempotency_keys (key, user_id, request_hash, file_key)
VALUES ($1, $2, $6, $3)
ON CONFLICT (key) DO NOTHING;          -- 0 rows inserted means: a retry
-- only if 1 row was inserted:
INSERT INTO files (file_key, project_id, name, created_by) VALUES ($3, $4, $5, $2);
COMMIT;
-- then write the empty checkpoint to S3 under a key derived from file_key

On a retry, the insert does nothing, the server reads the stored row, checks that request_hash matches this request's body (a mismatch is a 409), and returns the same file. If the first attempt died after the commit but before S3, the retry finds the file without a checkpoint and writes it; the S3 key is derived from file_key, so writing it twice is harmless.

Status codes

Recap

• Editing is a stream of small property changes over a WebSocket, ordered by the server.
• Metadata is ordinary HTTP against Postgres; retries are safe because the key is claimed before any side effect.

R1.5 Design Evolution: From Rows per Keystroke to Two Engines

Each step is a problem, your turn to think, the answer, and what it costs us.

Step 1.0: The Baseline

Every edit is a database write. A drag updates a row in a nodes table; other clients poll or get notified and re-read.

Synthesizing vector architecture diagram...

Every keystroke becomes a transaction on the one machine that also serves permissions, comments and billing. The database sits on the keystroke path.

Step 1.1: Edits Must Be Instant for Everyone

Primitive: WebSocket, SSE and Long Polling · Drill: The Gateway Restart That DDOSed the Chat Fleet (answered here: the deploy reconnect storm and its jittered backoff in "What it costs us", and WebSockets vs SSE in the wrong answers) · Primitive: Event Sourcing and CQRS (a snapshot plus later changes, the shape the journal takes in R1.9)

Step 1.2: Two People Changed the Same Property

Step 1.3: The Metadata Database Keeps Growing

Loop primitive: Replication, Quorums & Read-Your-Writes (Part 3: replication lag and stale reads; Part 4: read-your-writes)

Round 1 Step Summary

R1.6 Architecture v1

Synthesizing vector architecture diagram...

Two paths leave the browser. Edits go to the multiplayer server that owns the file and never touch Postgres; only checkpoints leave it, to S3. Everything else goes through the web tier and PgBouncer to one primary, with replicas taking lag-tolerant reads.

The web backend is Ruby; Figma (2023): "We use Ruby for the application backend, which services the majority of our web requests." How multiplayer checks a user's access to a file isn't published; in our design it asks the web tier once, when the WebSocket opens.

Trace: open a file and drag a shape

Synthesizing vector architecture diagram...

Postgres is touched once, at open, for a permission check. The drag itself goes client, server, other clients.

Trace: rename the file, then reload

1. PATCH /v1/files/fk_7Qm2xR goes to the web tier, then through PgBouncer to the primary: UPDATE files SET name = ..., commit.
2. The web tier notes "this user wrote at time T" in the session (our design).
3. The user reloads within a few seconds: the file list is read from the primary, because this session wrote recently. A read replica lagging by 500 ms would still show the old name.

Sources for this round

• Wallace, Rust in production at Figma, Figma blog, May 2, 2018: the TypeScript server launched two years earlier; each document on exactly one worker, slow operations locking a worker, the heavy-worker pool; a Rust child process per document; serialization over 10× faster; network handling kept in Node.js.
• Wallace, How Figma's multiplayer technology works, Figma blog, October 16, 2019: client/server over WebSockets, a process per document, why not OT, "inspired by" CRDTs but not true CRDTs, property-level last-writer-wins ordered by the server, flicker avoidance, object creation and IDs, the parent property and cycle rejection, fractional indexing, offline editing, metadata in Postgres.
• Goel, Under the hood of Figma's infrastructure, Figma blog, November 21, 2019: a single database instance on one of the largest machines in AWS; more than 80% of weekly active users outside the US; the Oregon datacenter; one Multiplayer instance per file.
• Liang, The growing pains of database architecture, Figma blog, April 4, 2023: the 2020 state (one RDS database, over 65% CPU at peak, traffic about 3× a year), the four tactical fixes, replication-lag sensitivity, Ruby and ActiveRecord.
• Tsung, Making multiplayer more reliable, Figma blog, October 20, 2022: multiplayer is authoritative and in memory; checkpoints every 30 to 60 seconds to S3; clients send updates every 33 ms; up to 60 seconds at risk.

Everything else in this round (the wire format, the routing table, the idempotency table, the replica routing rule, the trace details) is our design.

R1.7 Numbers

Figures marked published come from the sources above; the rest are assumptions or derived from them.

One busy file (assumptions: 10 people have it open, 3 edit at the same moment, 150 bytes per batch; the 33 ms cadence is published)

Tiny for one process. The point is the shape: a steady stream per file, which a process that owns the file absorbs easily and a shared database would pay for as 90 commits a second, per file.

Edits vs the whole database (published figures, two different years)

Even at the daily average, edits are 85% to 255% of everything the metadata database writes (25,500 ÷ 30,000 and 25,500 ÷ 10,000). Putting them in Postgres would roughly double its write load, or more.

Checkpoints: they scale with file size, not with edits (assumptions: a 5 MB compressed file; 45 s between checkpoints, the middle of the published 30–60 s)

This is the imbalance Figma described in 2022: "The contents of an entire file are often orders of magnitude larger than the incremental updates to the file."

A deploy (assumptions: 50,000 files open fleet-wide, 5 MB average, a 10-minute rolling deploy). Each file must checkpoint before it closes: 50,000 × 5 MB = 250 GB in 600 s, about 417 MB/s to S3, set by how much is open rather than by how much is being edited. Figma (2022): when multiplayer is re-deployed, "all files that are held in memory are closed, which causes a surge in checkpoints and subsequently increased load on the database."

One slow file on a shared worker (assumptions: 100 open files per worker in the TypeScript era; a 3-second encode of one huge file). Every change that arrives for any of those 100 files during the encode waits for it to finish. A change arriving at a random moment waits anywhere from 0 to 3 s, uniformly: 1.5 s on average, up to 3 s. With encoding 10× faster (published), the pause is 0.3 s; with a process per document, the other 99 files don't wait at all.

Database CPU runway (published: over 65% CPU at peak in 2020; 48 → 96 vCPUs; ~3× a year. Assumption: CPU load scales linearly with vCPUs)

The upgrade alone buys under ten months. With replicas taking some reads and new features going to new databases, Figma's "additional year of runway" is consistent.

Synthesizing vector architecture diagram...

From 32.5%, load passes 65% around month 8 and approaches 100% by month 12. (Month 3: 32.5 × 3^0.25 = 42.8; month 6: × 3^0.5 = 56.3; month 9: × 3^0.75 = 74.1; month 12: × 3 = 97.5.)

PgBouncer (published: client connections "in the thousands". Assumptions: 5,000 client connections; 60,000 queries/s at the peak; 1.5 ms average time in the database; ~10 MB per Postgres backend process)

Postgres runs one operating-system process per connection. Thousands of mostly idle connections cost memory and scheduling for work that 90 busy ones could do.

A database failover (assumptions: Multi-AZ, a 99.99% monthly availability target). AWS documents Multi-AZ failover times as "typically 60–120 seconds". The monthly budget is 30 × 86,400 s × 0.0001 = 259.2 s, so one failover spends 23% to 46% of it. Figma hasn't published its RDS configuration; the point is that one database is one blast radius.

R1.8 Trade-Offs

How to merge concurrent edits

Figma's reason (2019): "Our primary goal when designing our multiplayer system was for it to be no more complex than necessary to get the job done." With a central server available anyway, the CRDT's decentralization is overhead.

Where a file's live state lives

Checkpoint interval. 30 s risks at most 30 s of work and costs twice the checkpoint bytes of 60 s. Figma's published range is 30 to 60 seconds; the journal (R1.9) later made the interval a cost knob instead of a durability knob.

R1.9 Failure Modes

Go deeper: the journal Figma added (published 2022), and how it fences a stale owner.

The 60-second loss window is the weak spot of Round 1. Figma's fix: "a write-ahead log", which it calls the journal. Each change gets a per-file sequence number, "an incrementing integer associated with the file"; every checkpoint records the sequence number it includes. After a crash, the new owner loads the checkpoint and then "queries for all entries that are newer (i.e. have a higher sequence number) than the checkpoint". Results Figma reported: the journal "handles >2.2B received changes per day, persists 95% of changes within ~600ms"; the goal was "<1s of data loss". Figma describes the journal as "asynchronously written to as multiplayer accepts incoming changes", so (our reading) an edit can be broadcast before its journal entry is durable; that's the sub-second window.

• Store: DynamoDB. Figma considered Postgres but "the volume of writes would require us to consider a horizontally-scalable database—and we’re not there quite yet with Postgres."
• Batching: entries cover a range, start_sequence_number to end_sequence_number. Loading checkpoint 7 and replaying an entry that covers 5–9 still ends at the right state for 9. Changes 5 and 6 may briefly set a property back to an older value, but 7, 8 and 9 are applied after them, in order, and under last-writer-wins the last value applied is the one that stays. Figma (2022): "applying that entry will still result in the correct file at sequence number 9 due to the last-writer wins conflict resolution strategy we use." That's why replay must keep the original sequence numbers and order: renumbering, or applying entries out of order, would let an old value win.
• One writer per file. Two servers that both think they own a file would write conflicting histories. Figma (2022): "Multiplayer writes a (lock UUID, file key) entry to take ownership of that file. When new entries are being written to the journal, the update is conditional on the lock UUID matching in the other table." And journal entries "are not read until after ownership is acquired, and the reads are strongly consistent."

Synthesizing vector architecture diagram...

The check that stops the stale owner happens in the store, on every write, and needs no clock. Ownership changes hands by a conditional write, so two contenders can't both win.

Figma doesn't say which DynamoDB call makes a journal write conditional on an item in another table; a transaction (TransactWriteItems) with a ConditionCheck on the lock item plus the Put of the entry is one way (our reading). Takeover conditioned on the previous owner's UUID is also our design. What the design deliberately avoids, and why it matters in DynamoDB:

• No time in the condition. DynamoDB conditions compare stored values; the service offers no server time to compare against. Ownership is an identity (the UUID), never "expires at".
• No TTL for freeing locks. DynamoDB TTL deletes expired items only eventually, typically within a few days, so it can't be what releases a lock.
• No global tables for the lock. Global tables replicate with last-writer-wins and check conditions only against the local copy; two Regions could each grant ownership. Figma also rejected global tables for the journal on cost ("increase the cost of the feature by 6x"). For recovery from a lost Region it relies on checkpoints: S3 is "already set up to be replicated cross-region", and all journal changes are checkpointed within 30 minutes.

Why not optimistic concurrency on the entries alone, say "append sequence 41 only if 41 doesn't exist"? That stops two writers from writing the same number, but a stale owner that's behind could still write numbers the new owner hasn't reached yet, and the history would interleave two different in-memory states. Checking ownership on every write rejects the stale owner's whole history in one comparison. A lock with a TTL and no check in the store fails the other way: an owner paused past the TTL wakes up and writes anyway.

Loop primitive: Write-Ahead Log, fsync & Group Commit (Part 1: what "acknowledged" has to mean; Part 5: group commit, the batching idea) · Loop primitive: Leases, Fencing Tokens & Distributed Locks (Part 4: the pause, the zombie and the fencing token; Part 5: conditional writes are the check) · Drill: The GC Pause That Corrupted Shared Storage (answered here: why a TTL lock doesn't stop a paused owner, and per-entry version checks vs an ownership check in the store)

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Separates the two workloads early and keeps the database off the keystroke path, with numbers.
• Chooses WebSockets for a two-way stream, and a single owner per file that orders changes.
• Describes last-writer-wins per property with server order, and names what it can't do (concurrent text).
• Explains the durability trade-off of periodic checkpoints and how a crash loses up to one interval.
• Buys database time with the obvious levers (a bigger machine, replicas, a pooler) and quantifies how long they last.

Follow-up questions

1. "Why not make every client talk to every other client directly, peer to peer?" Answer: then there's no single authority to order conflicts, validate changes or reject a cycle, which is exactly what a true CRDT has to pay for. Figma chose the server as the authority because it simplifies everything else, and every file needs a server copy for durability anyway.

2. "A file becomes enormous. What happens?" Answer: checkpoints get slower and bigger (they scale with file size), and in the single-threaded era one huge file stalled its neighbours. The fixes: a process per document so it stalls only itself; faster serialization; later, a journal so durability no longer depends on writing the whole file often. Figma (2022) reported that "for the worst 5% of files, creating a checkpoint can take ~4 seconds or more".

3. "Can a user lose work?" Answer: their own unacknowledged changes, no: the client keeps them and re-sends after reconnecting. Changes the server acknowledged but hadn't checkpointed, yes, up to the checkpoint interval in this era. The journal cut that to under a second for 95% of changes.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "Era 2: Vertical Partitioning Under Pressure"

~40 min · Senior SDE (L6) · 2020–2022 · one database → about a dozen (published) · traffic ~3× a year (published) · ~30,000 row writes/s across all databases (planning figure) · headroom without long outages

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "Figma has two engines. Live editing runs on multiplayer servers: each open file is owned by one process that holds it in memory, receives every editor's changes over WebSockets, orders them, resolves conflicts per property with last-writer-wins in the server's order, and broadcasts. It checkpoints the whole file to S3 every 30 to 60 seconds, and since 2022 also writes a journal to DynamoDB, fenced by an ownership UUID. Postgres is never on the keystroke path. Everything else (users, teams, files, permissions, comments) lives in one RDS Postgres primary. We bought time with the largest instance, r5.24xlarge, read replicas for lag-tolerant reads, new databases for new features, and PgBouncer in front of thousands of connections. At 3× growth a year that buys about a year. Open costs: one primary takes every write, and everything shares its fate."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: the edit path never touches Postgres; everything else shares one primary.

Round 1 step summary

Open costs: a single write primary with no bigger machine to move to; writes are a large share of its load; every feature's queries compete for the same CPU.

R2.1 The Scope Raise

Interviewer: "It's 2020. The database is on the biggest instance RDS sells, peaking above 65% CPU, and traffic triples every year. We're also preparing to launch a second product. We can't take maintenance windows, and we can't ask every product team to rewrite their queries. Give us years of headroom, not months."

Scope change

The "Not yet" list from R1.2 comes back: partitioning is in scope now; horizontal sharding is still not.

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

A table-group map. Every application instance must know which database holds each table. Figma (2024): "With vertical partitioning, we relied on a simple, hard-coded configuration file that mapped tables to their partition." An illustrative version (the table names are ours):

yamlCopy
# table-group map, version 14 (illustrative)
version: 14
partitions:
  main:
    pgbouncer: pgbouncer-main.internal
    tables: [users, organizations, teams, projects, permissions]
  files:
    pgbouncer: pgbouncer-files.internal
    tables: [files, file_versions, file_thumbnails]
  comments:
    pgbouncer: pgbouncer-comments.internal
    tables: [comments, comment_reactions]

Later Figma replaced per-client knowledge with a service: "We’ve since introduced a new query routing service which will centralize and simplify routing logic as we scale to more partitions" (2023). That service is the ancestor of Round 3's DBProxy.

A migration runbook, as published (2023). "At a high level, we implemented the following operation (steps 3–6 complete within seconds for minimal downtime)":

Error contract during a move (our design). A query that reaches the old database for a moved table fails with Postgres's "permission denied" (SQLSTATE 42501), which the data layer turns into a retryable error that reloads the table-group map. A query that waits in a paused pooler longer than its timeout fails as a normal timeout, and is retried with jittered backoff.

R2.4 Design Evolution: One Database Becomes a Dozen

Step 2.1: One Database Is Near Its Ceiling

Primitive: Database Sharding and Partition Keys (vertical vs horizontal partitioning)

Step 2.2: Which Tables Can Move Together?

Step 2.3: Move the Tables Without Downtime

Primitive: Change Data Capture and the Outbox Pattern · Loop primitive: Change Streams & the Transactional Outbox (Part 1: why writing twice fails; Part 5: reading the database's own log, including slot limits; Part 7: republish when a slot is lost) · Loop primitive: Replication, Quorums & Read-Your-Writes (Part 8: catching up by log or by snapshot) · Loop primitive: Write-Ahead Log, fsync & Group Commit (Part 9: the WAL in B-tree engines, where LSNs come from)

The move as a state machine (our design around Figma's steps)

Synthesizing vector architecture diagram...

Until Serving, aborting is just un-pausing on the old database, since no application write ever reached the new one. After Serving, the only way back is a full move in the other direction, which fences the new copy first.

Step 2.4: Huge Tables and Vacuum

Primitive: Database Isolation Levels, ACID and Concurrency Anomalies (MVCC row versions, which vacuum cleans up)

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Each table group has its own pooler and primary. The application picks the pooler by table; only the poolers can reach the databases. LiveGraph now has to read several replication streams, not one.

The multiplayer tier is unchanged from Round 1.

Trace: moving the comments group (our timings; the steps are Figma's)

1. Weeks before: the application sends every query for comments and comment_reactions to pgbouncer-comments, which still points at the original database. Validators show no transactions that mix comments with other groups.
2. Create the new instance; create a publication for the two tables on the original, and a subscription on the new database with its secondary indexes dropped. Initial copy: hours. Rebuild the indexes. Lag falls to near zero.
3. PAUSE on the comments PgBouncers. New comment queries wait.
4. REVOKE the application role's access to the two tables on the original; after about 2 s, terminate the few sessions still inside a transaction; take and release the table lock; sample LSN 3F/9A0012C8.
5. The new database reports it has replayed past 3F/9A0012C8 within a second.
6. Stop the subscription, set each sequence above its copied maximum, start reverse replication from new to original without an initial copy.
7. Point pgbouncer-comments at the new database and RESUME. The waiting queries run there.

Sources for this round

• Liang, The growing pains of database architecture, Figma blog, April 4, 2023: the 2020 limits and tactical fixes; options evaluated; vertical partitioning; AAS from pg_stat_activity every 10 ms; runtime validators and Snowflake; goals (under a minute, automated, undoable); the six steps; PgBouncer split first and security groups; logical replication's three advantages; dropping indexes during the copy; pause, revoke, cancel, LSN, promote, reverse replication; outcomes (2 tables first, 50 last in October 2022, ~30 s and ~2% per move, largest partition ~10% CPU); the new query routing service.
• Steele, How Figma’s databases team lived to tell the scale, Figma blog, March 14, 2024: a dozen vertically partitioned databases by the end of 2022; the hard-coded table-to-partition configuration; the vacuum risk; avoiding double writes.
• Bandi, Keeping it 100(x) with real-time data at scale, Figma blog, May 17, 2024: LiveGraph's global-ordering assumption and the stopgap of combining streams.
• Chen and Kim, GraphQL, meet LiveGraph, Figma blog, October 14, 2021: LiveGraph tails the replication stream, about 10,000 writes/s.
• PostgreSQL documentation: Routine vacuuming, Vacuuming settings, Logical replication restrictions, Replication settings; PgBouncer usage (PAUSE, RESUME), checked September 2026.

Figma didn't publish its table groups, its lock step, how it handled sequences, its slot limits, its autovacuum settings or its partition instance sizes; everything on this page about those is our design.

R2.6 Numbers and Cost

Figures marked published come from the sources above; everything else is an assumption or derived from one.

Moves and their impact (published)

Copy time (assumptions: a 3 TB table group; 150 MB/s bulk copy without secondary indexes; index maintenance row by row makes the copy 10× slower; 3 h to rebuild indexes)

Consistent with Figma's published before-and-after: "days, if not weeks" became "a matter of hours".

WAL pinned by the replication slot (assumptions: the original database writes 20,000 rows/s at about 1 KB of WAL each)

A replication slot keeps every WAL segment the subscriber hasn't confirmed. For the whole copy, that's all of it:

So the original database needs about 620 GB of free storage just for the move, and more if the copy stalls. Set max_slot_wal_keep_size (default −1, unlimited) to a cap the disk can afford, say 800 GB. Past the cap the slot is lost and the subscriber "may no longer be able to continue replication due to removal of required WAL files"; the plan for that case is to drop the subscription, empty the target tables and start the copy again (a republish), instead of letting a full disk stop the original database's writes.

The pause, step by step (our design; Figma: steps 3–6 "complete within seconds")

Each step depends on the previous one, so the times add. One nuance: PgBouncer's PAUSE returns only once in-flight transactions have released their server connections, so in practice it runs alongside the revoke, grace and terminate steps rather than before them (Figma: "While PgBouncer pauses new connections, we revoke clients’ query privileges"); the 0.1 s in the table is the time to stop new queries, and the ~4.7 s total still holds. Figma's observed impact was about 30 s; the rest plausibly comes from connections re-establishing, cold caches on the new database and clients backing off before retrying. That split is our guess; the post doesn't break the 30 s down.

What a request feels during a 4.7 s pause (assumption: a 3 s client timeout). A query arriving at a random moment in the pause waits for the rest of it: anywhere from 0 to 4.7 s, uniformly, 2.35 s on average. It times out if it waits more than 3 s, that is, if it arrives in the first 4.7 − 3 = 1.7 s: 36% of the queries that arrive during the pause (1.7 ÷ 4.7). The shorter the grace period, the fewer time out.

Error budget (assumption: a 99.99% monthly target). A 30-day month is 2,592,000 s; the budget is 259.2 s of full outage. One move costs about 30 s × 2% = 0.6 s of equivalent full outage. 259.2 ÷ 0.6 = 432 moves a month would fit. Figma wrote that it had "successfully performed the partitioning operation many times in production", over roughly two years (our inference from the post's dates): the moves are cheap; the risk is in getting one wrong, which is why they're automated and reversible.

Headroom (published: ~10% CPU on the largest partition; ~3× a year)

About two years, if every partition grows at the overall rate. Some tables grew faster (Round 3).

Cost: capacity bought at the same unit price (illustrative sizes; us-west-2 on-demand, Multi-AZ, 720 hours; Figma didn't publish its instance mix or whether it uses Multi-AZ)

Five times the vCPUs for five times the bill: $0.25 per vCPU-hour both ways. Vertical partitioning doesn't make capacity cheaper; it makes more of it possible, and lets small partitions run on small instances ("we’ve decreased the resources allocated to some of the lower traffic partitions", Figma 2023). Read replicas and storage come on top.

R2.7 Trade-Offs

Vertical partitioning vs horizontal sharding

Replication-based moves vs dual writes

Logical vs streaming replication for a move

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a senior (L6) answer adds over L5

• Picks the cheaper step first, and says what it can't do (split one table).
• Chooses tables by measurement: load share and coupling.
• Designs a live move: split the connection layer first, logical replication with deferred indexes, a pause, an LSN check, a way back.
• Makes the old copy refuse writes permanently, in the database, and explains why a cache interval isn't a fence.
• Knows the logical-replication traps: slots pinning WAL, sequences, DDL.
• Does the XID arithmetic for the biggest tables.

Follow-up questions

1. "Why not restore an RDS snapshot to create the new database?" Answer: it's fast to create, but it brings the whole database's storage along, and Figma wanted "a much smaller storage footprint in the destination database"; and it must line up exactly with where replication starts. Logical replication of just the moving tables, with indexes built afterwards, copied in hours.

2. "Each move cost about 30 seconds of partial availability. How would you shrink it?" Answer: shorten the grace period (most queries are short; Figma cancelled "a little under 10"), have the new database's connections and caches warm before resuming, and make clients retry quickly with jitter instead of waiting out long timeouts. The pause itself (R2.6) is about 5 s in our design; the rest is recovery.

3. "Why revoke privileges instead of just repointing PgBouncer?" Answer: repointing controls the path we know about. The revoke stops every path, including a misconfigured client, a forgotten cron job or a pooler that didn't get the new config, and it stays in force until someone deliberately grants access back.

4. "Would Postgres table partitioning have avoided all this?" Answer: declarative partitioning splits a table into smaller tables on the same server. It helps vacuum and index maintenance (each partition is smaller) but not CPU, IO or connection limits of the one machine. It's a tool for step 2.4, not for step 2.1.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "Era 3: Horizontal Sharding Without Stopping"

~45 min · Principal (L7) · late 2022–2024 · first horizontally sharded table in September 2023 (published) · the database stack almost 100× its 2020 size (published) · one hot table: 6 TB, 30,000 row writes/s, 120,000 IOPS (assumptions) · near-zero-downtime shard splits that can be rolled back

R3.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 3. If you're starting here, it's everything you need from Rounds 1 and 2.

Rounds 1 and 2 in 60 seconds. "Figma keeps live editing out of Postgres: one multiplayer process per open file holds it in memory, orders everyone's changes, checkpoints to S3 and journals to DynamoDB under an ownership lock. Metadata lived on one RDS Postgres primary until, in 2020, it was on the largest instance, peaking at over 65% CPU, with traffic tripling yearly. We then split it by table group into about a dozen databases. Each move split PgBouncer first, copied the tables with logical replication while their indexes were dropped, paused the group for seconds, revoked the application's access on the old database so it can never be written again, waited for the new database to replay past the old one's LSN, and switched, with reverse replication kept for rollback. Each move cost about 30 seconds of partial availability. Open costs: one table can't be split this way, and some tables are several terabytes, with vacuum and IOPS limits coming within months."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: many databases, but each table still lives whole on exactly one of them.

Round 2 step summary

Open costs: the biggest tables can't be split by table; their databases are running out of IOPS; vacuum on them gets riskier every month.

R3.1 The Scope Raise

Interviewer: "It's late 2022. Some single tables are several terabytes, and traffic to them is growing ~3× a year. Their databases will run out of IOPS within months, and vacuuming them is already causing incidents. Split those tables across machines. You can't rewrite the product, you can't take downtime, and every step has to be reversible."

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

A shard key per table, grouped into colos (published concept; the table names are ours). Figma (2024) "selected a handful of sharding keys like UserID, FileID, or OrgID. Almost every table at Figma could be sharded using one of these keys."

What SQL still works (published rules; the table layout is ours)

Figma's summary (2024): "all range scan and point queries are allowed, but joins are only allowed when joining two tables in the same colo and the join is on the sharding key."

The topology DBProxy routes by (our model of what Figma describes)

Synthesizing vector architecture diagram...

A table belongs to a colo; a colo's key space is cut into logical shards by hash range; each logical shard maps to exactly one physical database at a given topology version.

Figma (2024) enforced invariants on this model, for example "every shard ID should be mapped to exactly one physical database", and built it to "deliver real-time updates in under a second". Its diagram shows the topology library backed by S3 and etcd. The logical-shard count, the hash function and the version field are our choices.

The fence on every physical database (our design, the same rule as the hotel and wallet loops):

sqlCopy
CREATE TABLE shard_fence (
  logical_shard    integer PRIMARY KEY,
  state            text    NOT NULL CHECK (state IN ('serving', 'moved')),
  topology_version bigint  NOT NULL,
  moved_to         text                     -- physical database now serving it
);
-- local to each database: never included in a replication publication

Error contract (our design). A write that finds its logical shard moved rolls back and returns a retryable "shard moved" error carrying the new topology version; DBProxy reloads the topology and retries once. A query DBProxy doesn't support returns a non-retryable error naming the rule it broke, so the call site gets fixed rather than retried.

R3.4 Design Evolution: Split a Table Without Stopping

Step 3.1: Pick Shard Keys

Go deeper: the organization that's bigger than a shard. Hashing spreads keys evenly, not load: one organization with a hundred thousand members is one org_id, so all its org-colo rows sit in one logical shard. Figma hasn't published how it handles this; a design that fits:

• Carve out the logical shard. Because the unit of placement is the logical shard, we can move the one containing the big organization to its own physical database, with the same split procedure as step 3.5. Its neighbours in that hash range move with it; that's the price of fixed ranges.
• If one organization alone saturates a database, placement can't help: every one of its rows is on one key. The fix is to move its heaviest tables into a colo with a finer key (file, not organization), which is a data-model change, not an operation.
• "One query over every organization" (a platform-wide report) should not be a scatter-gather through DBProxy: each scatter-gather "contributes the same amount of load as it would if the database was unsharded" (Figma, 2024). Run it on a copy of the data in a warehouse instead, minutes behind; Figma already uses Snowflake as its data warehouse (2023).

Primitive: Database Sharding and Partition Keys · Loop primitive: Sharding, Hot Keys & Rebalancing (in preparation) · Drill: One Customer, One Shard, One Outage (answered here: the tenant too big for its shard in "Go deeper", and why a cross-tenant report goes to the warehouse, not a scatter-gather)

Step 3.2: Sharding Is Risky and Hard to Undo

Step 3.3: The Application Sends Plain SQL

Primitive: API Gateway and Reverse Proxy (a proxy that inspects and routes each request)

Step 3.4: Cross-Shard Transactions and Foreign Keys

Primitive: Two-Phase Commit and Saga Orchestration · Primitive: Database Isolation Levels, ACID and Concurrency Anomalies · Loop primitive: Change Streams & the Transactional Outbox (Part 1: why writing twice fails; Part 2: the outbox in one transaction; Part 5: reading the database's own log) · Loop primitive: Idempotency & Effectively-Once Processing · Drill: The Dual-Write That Broke Search Consistency (answered here and in R3.7: the dual write in the wrong answers, and why tailing the log beats polling, as LiveGraph found) · Loop: Design a Distributed Unique ID Generator (worker numbers and clocks)

Step 3.5: The Physical Split

Primitive: Change Data Capture and the Outbox Pattern · Loop primitive: Leases, Fencing Tokens & Distributed Locks (Part 5: conditional writes are the check; Part 7: single writers) · Loop primitive: Sharding, Hot Keys & Rebalancing (in preparation) · Loop: Design a Hotel Reservation System (Round 2, step 2.4: a bucket move whose old cluster keeps a bucket_state row read FOR SHARE in every transaction and never removed) · Loop: Design a Digital Wallet System (Round 2: carving buckets out of a hot shard, with a permanent "moved" row on the old shard)

The life of one logical shard across a split

Synthesizing vector architecture diagram...

The only way back to the old database, once version v+1 is out, is a full reverse move; no timer or cache expiry ever re-opens it.

Round 3 Step Summary

R3.5 Global Architecture

Synthesizing vector architecture diagram...

Every metadata query now passes through DBProxy, which reads the topology and picks poolers; the poolers reach either the old unsharded databases or the sharded ones. The multiplayer tier didn't change. LiveGraph's invalidators follow the same database topology.

Figma (2024) on LiveGraph after this change: "The invalidator is sharded the same way as the physical databases and tails a single replication stream. It is the only service with knowledge about database topology." Its caches are "sharded by query hash" and agnostic to the database layout.

Trace 1: a single-shard query

Synthesizing vector architecture diagram...

One shard, the whole query pushed down. Three components touched on the way: DBProxy, a pooler, a database.

Trace 2: a rejected query

1. The application sends SELECT ... FROM files f JOIN user_favorites u ON u.file_key = f.file_key WHERE u.user_id = 42.
2. The logical planner sees files in the file colo and user_favorites in the user colo: a join across colos.
3. DBProxy returns an error naming the rule ("join across colos"). Nothing reaches a database.
4. The fix at the call site: read the user's favorites on the user shard (one shard, by user_id), then fetch those files by file_key: a batch of single-shard reads, or one scatter-gather if the batch is large.

Trace 3: the physical split. Shown in step 3.5: pause, fence, LSN, wait for all four, publish version v+1, resume.

Sources for this round

• Steele, How Figma’s databases team lived to tell the scale, Figma blog, March 14, 2024: almost 100× growth since 2020; the limits (table size, vacuum, RDS IOPS); goals; options evaluated; colos and keys; hashed routing; logical vs physical sharding; views, poolers per view, feature flags, the 10% overhead and shadow reads; DBProxy in Go, its planner, scatter-gather, shadow planning, the 90% subset and join rules; the topology service; full logical replication; 1 → N failover; September 2023 and ten seconds of partial availability; the future-work list; reassessing NewSQL.
• Liang, The growing pains of database architecture, Figma blog, April 4, 2023: the move machinery the split reuses.
• Bandi, Keeping it 100(x) with real-time data at scale, Figma blog, May 17, 2024: LiveGraph's invalidators sharded like the physical databases; dbproxy as the service that knows database topology.
• PostgreSQL documentation: CREATE VIEW (WITH CHECK OPTION), Routine vacuuming (multixacts), Logical replication restrictions, checked September 2026.
• AWS documentation: Amazon RDS DB instance storage (io2 Block Express up to 256,000 IOPS per volume), Quotas for Amazon RDS, Amazon RDS pricing (data transfer), and the AWS Price List for RDS and S3 in us-west-2, checked September 2026.

Figma didn't publish its logical-shard count, hash function, physical shard counts, instance classes, how it fenced the old copy, how it cleans up the extra rows, or how its product handles partial commits; those parts of this round are our design.

R3.6 Numbers and Cost

Figures marked published come from the sources above; everything else is an assumption or derived from one.

Why now: the IOPS runway (assumptions: the hot table's database does 30,000 row writes/s at the peak at ~4 IOPS each, heap, indexes and WAL together; published: ~3× a year)

A database's IOPS ceiling is the lower of two limits: the volume's (up to 256,000 IOPS for io2 Block Express on RDS today) and the instance's EBS limit. The instance limit bites first on most classes. AWS's EC2 tables list 80,000 IOPS for r5.24xlarge (the 2020 instance), 260,000 for r5b.24xlarge and 86,667 for r5b.8xlarge. So our hot table's database has to be a db.r5b.24xlarge to reach 120,000 IOPS at all, and its ceiling is then min(256,000, 260,000) = 256,000.

"Only months of runway", as Figma wrote. (The IOPS ceiling in Figma's own 2022 setup isn't published; we use today's documented limits.)

Logical and physical shards (our choices: 64 logical shards; the first split goes 1 → 4 physical, each a db.r5b.8xlarge with an 86,667-IOPS instance limit)

The instance limit, not the volume, sets each shard's runway; a bigger class per shard (db.r5b.24xlarge) would lift it to 256,000 at about three times the instance price. After 64 physical databases, one per logical shard, splitting further would mean re-hashing into more logical shards. Pick the logical count for a decade, not for the first split; Figma hasn't published its count.

The price of full copies (us-west-2: io2 storage $0.25/GB-month in Multi-AZ)

RDS doesn't shrink an instance's allocated storage in place, so each new database keeps its 6,000 GB. Deleting the other shards' rows frees space inside Postgres, and the shard grows into it: at 3× a year, 1.5 TB becomes 6 TB in $\ln 4/\ln 3 = 1.26$ years. Treat the full copy as prepaid headroom.

One table's databases, before and after the first split (illustrative sizes; us-west-2 on-demand, Multi-AZ, 720 hours)

About $13,320 a month more (+26%) for a 35% higher IOPS ceiling today (346,668 ÷ 256,000 = 1.35), and, more important, the ability to keep splitting up to 64 databases without touching the application. Most of the bill is provisioned IOPS, not instances.

DBProxy fleet (assumptions: 540,000 queries/s at the peak, 60,000 × 3², two years of 3× growth after Round 1; 20,000 queries/s per DBProxy instance; three AZs, and losing one must not overload the rest)

Round up per AZ, not for the fleet: 13.5 × 3 = 40.5 rounds to 41, which can't be spread evenly and leaves one AZ short.

Latency: count every component a request touches (assumptions: DBProxy adds 0.2 ms of parsing and planning and one 0.1 ms same-AZ hop; each component's latency is independent)

• A single-shard query now touches three components (DBProxy, a pooler, a database) instead of two: about +0.3 ms on average.
• Tails compound. If each component is above its own p99 1% of the time, a request avoids all three tails with probability 0.99³ = 0.970, so 3.0% of requests see at least one component's p99, not 1%.
• Scatter-gather is worse. The answer waits for the slowest shard, so it's the max over all of them:

Synthesizing vector architecture diagram...

At 64 shards, the p99 of one database becomes roughly the median of a scatter-gather. That's the latency side of Figma's load argument against scatter-gathers.

The split's pause (our chain; published: "ten seconds of partial availability on database primaries")

As in Round 2, PAUSE returns only once in-flight transactions have drained, so step 1 overlaps steps 2 and 3 in practice; the total doesn't change.

What a request feels (assumption: DBProxy holds a write for a moving shard for up to 2 s, then returns a retryable error). A write arriving at a random moment in a 10 s window waits the rest of the window: 0 to 10 s, uniformly, 5 s on average. It rides through only if it arrives in the last 2 s: 20% complete after a delay, 80% get the retryable error. With our own ~5.7 s chain instead of the published 10 s, 2 ÷ 5.7 = 35% ride through and 65% get the retryable error. Reads that tolerate lag keep going to replicas: Figma reported "no availability impact on replicas".

Cross-AZ transfer on the query path (assumptions: an average of 270,000 queries/s, half the peak; 2 KB per response, requests negligible; three AZs; the primary of each database sits in one AZ. Prices: EC2 to EC2 across AZs $0.01/GB each way, so $0.02 per GB crossing; EC2 to RDS across AZs $0.01/GB, charged on the EC2 side only; RDS Multi-AZ and read-replica replication is free)

Keeping application → DBProxy → pooler inside one AZ saves about $37,300 a month. The last hop can't be avoided for two-thirds of traffic, because a primary lives in exactly one AZ.

Quotas: check them before the split, not during it. The default quota is 40 DB instances per Region (L-7B6409FD) and 100,000 GB of total storage across all RDS instances (L-7ADDB58A), both adjustable. Counting primaries and read replicas (assumptions: 12 partitions averaging ~3,000 GB, one read replica each): 24 instances and 72,000 GB before the split; the four new databases add 4 instances and 24,000 GB, reaching 28 instances and 96,000 GB. The next split, 4 → 8, would pass the storage quota. Request increases ahead of each split.

R3.7 Trade-Offs

Build a proxy on RDS Postgres, or adopt a sharded database?

Figma's stated reasons (2024): switching stores meant "a complex data migration to ensure consistency and reliability across two different database stores", rebuilding "domain expertise from scratch", and "only months of runway". "We favored known low-risk solutions over potentially easier options with much higher uncertainty, where we had less control over the outcome." Figma's posts don't mention Postgres sharding extensions, so we can't say how it weighed them. Amazon now offers Aurora PostgreSQL Limitless Database (sharded Postgres on Aurora); it isn't part of Figma's story. Figma also said it would revisit the choice: "NewSQL stores have continued to evolve and mature. We will finally have bandwidth to reevaluate the tradeoffs".

Logical sharding through views vs going straight to physical

Full vs filtered logical replication

Polling vs tailing the log for change consumers. LiveGraph (2021) chose to "tail the database replication log" because polling would "multiply the load on the database" and forces each query to pick a polling interval; the same reasoning applies to step 3.4's outbox relay. A relay that polls the outbox table every 500 ms runs a query per shard every interval even when nothing changed, adds a delay of 0 to 500 ms (250 ms on average) to every event, and must mark or delete the rows it has sent, which is more write load and more dead rows for vacuum. A relay that tails the WAL (Debezium-style, through a logical replication slot) reads changes the database already wrote, in commit order, with no extra queries. The cost of tailing is what Round 2 found: the reader must follow the topology, and a slot pins WAL until it's read.

What changed from Round 1. Round 1 took the database off the keystroke path. Round 3 made the database itself a routed system, and it did so by keeping every property Round 2 relied on: moves by replication, a pause of seconds, a permanent refusal on the side being left, a way back. The lesson of the whole loop: grow in the order that keeps each step reversible, and put the safety of every move in the database that's being left, not in the clients that might still point at it.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals OPS 8 · REL 6

A blocking query on a shard OPS 10

1. Find who blocks whom:

   sqlCopy
   SELECT pid, usename, state, now() - xact_start AS xact_age,
          pg_blocking_pids(pid) AS blocked_by, left(query, 80) AS query
     FROM pg_stat_activity
    WHERE state <> 'idle'
    ORDER BY xact_start;

2. If the blocker is an application query, SELECT pg_cancel_backend(<pid>); stops the statement. If it's idle inside a transaction, cancel does nothing: SELECT pg_terminate_backend(<pid>); ends the session and rolls its transaction back.

3. If the blocker is an autovacuum "(to prevent wraparound)", don't kill it; it will restart and the XID age keeps rising. Wait, or move the conflicting work.

A shard's primary fails over REL 11

1. RDS Multi-AZ promotes the standby; AWS documents failover as "typically 60–120 seconds". Only that shard's key range is affected; other shards and replicas keep serving.
2. Confirm the new primary and AZ (command 1). The pooler reconnects by DNS name.
3. Confirm that the replication slots used by LiveGraph or an outbox relay exist on the new primary. A Multi-AZ DB instance's standby is a synchronous copy of the storage, so its slots should survive with the volume; a read-replica promotion keeps them only with RDS for PostgreSQL 17+ failover slots. If a slot is missing, recreate it and republish from the stored source.
4. Watch DBProxy errors for that shard fall back to zero.

Go deeper: CLI playbook

Commands an on-call engineer runs one at a time; replace names and times with real ones.

textCopy
# 1. Status, Multi-AZ and AZs of one shard's primary
aws rds describe-db-instances --db-instance-identifier files-shard-03 --query "DBInstances[0].[DBInstanceStatus,MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]"

# 2. Highest transaction-ID age on that shard, per minute, for an hour
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name MaximumUsedTransactionIDs --dimensions Name=DBInstanceIdentifier,Value=files-shard-03 --start-time 2026-09-28T09:00:00Z --end-time 2026-09-28T10:00:00Z --period 60 --statistics Maximum

# 3. WAL held back by the most-lagging replication slot
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name OldestReplicationSlotLag --dimensions Name=DBInstanceIdentifier,Value=files-shard-03 --start-time 2026-09-28T09:00:00Z --end-time 2026-09-28T10:00:00Z --period 60 --statistics Maximum

# 4. A planned Multi-AZ failover of one shard (a drill, or before maintenance)
aws rds reboot-db-instance --db-instance-identifier files-shard-03 --force-failover

# 5. Quotas to check before a split: DB instances, and total storage in GB
aws service-quotas get-service-quota --service-code rds --quota-code L-7B6409FD
aws service-quotas get-service-quota --service-code rds --quota-code L-7ADDB58A

R3.10 Pillar Check

Figma (2024) on that sustainability point: "in our non-production environments, we can keep the same logical topology as production, but serve the data from many fewer physical databases."

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Picks shard keys from the data model (a few keys, colos) and explains hashing vs ranges with the ID formats in play.
• Separates logical from physical sharding, and uses it to find bugs while rollback is cheap.
• Designs the router: parse, plan logically, plan physically; a supported subset chosen from production traffic; the cost of scatter-gathers in load and in tail latency.
• Replaces cross-shard transactions with ordered writes, operation records, an outbox and a sweeper, and knows that IDs and unique indexes change too.
• Makes a 1 → N split safe: full copies, an abort point, a topology version as the commit point, and a permanent fence on the old copy checked under a lock.
• Prices it: provisioned IOPS, full-copy storage, cross-AZ hops, quotas.

Follow-up questions

1. "Why did Figma write DBProxy in Go?" Answer: the post says only that it's "a new golang service"; it doesn't give reasons. A fair guess, labeled as one: a network service handling many concurrent connections is Go's home ground, and LiveGraph's newer services are in Go too. Don't state a reason Figma didn't give.

2. "The Oregon Region is lost. What happens?" Answer: Figma hasn't published a multi-region failover design, so this is ours. Metadata: an RDS cross-Region replica is asynchronous, so the recovery point is its lag; promoting it needs capacity in the other Region (instances, storage and quotas already raised) and must respect any data-residency commitments. Files: Figma (2022) keeps checkpoints replicated across Regions and checkpoints journal changes within 30 minutes, so file edits could lose up to that window, plus however far S3's cross-Region replication is behind. Deciding the Region is gone must be done from outside it, and switching DNS should be a gated, human-approved step. Anything with a single writer (a file's multiplayer owner, the topology) needs a new epoch in the new Region: a new topology version and new ownership UUIDs. The epoch alone doesn't stop the old Region, though, because its databases and its DynamoDB lock table are separate copies that never saw the new epoch. So the returning Region must be fenced for good before anything in it can take traffic: keep it cut off from clients (DNS and load balancers stay pointed away, security groups closed to the application), and on its databases mark every logical shard moved in shard_fence and revoke the application role, then rebuild them as replicas of the new primaries rather than letting them rejoin as writers. Its multiplayer fleet stays stopped; files are re-homed only from the new Region's copies. A Region that comes back is a source of stale writers, never a candidate primary, until it has been rebuilt from the survivor.

3. "A table has no good shard key. What do you do?" Answer: leave it unsharded on its own vertical partition as long as it fits; if it doesn't, add a key during a planned data-model change, accepting the backfill that Figma avoided for its first tables. Don't force it into a colo whose key it doesn't have.

4. "Isn't hashing the key bad for 'list my recent files'?" Answer: only if the list is a range over the shard key. "Recent files of user U" is a query in the user colo filtered by user_id and sorted by time within one shard: one shard, pushed down. A range over file_key itself would scatter, which Figma found rare enough to accept.

Interview gotchas from this round's wrong answers

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint. For another company that split a growing database while it kept running, see the Uber loop (Schemaless) and the Discord loop (a migration of trillions of rows). For bucket moves fenced on the old side, see the hotel and wallet loops.

The Two Sentences That Matter Most

• Opening any round: "Live editing and relational metadata are two different workloads, so I'll keep each open file in memory on one server that orders edits and checkpoints it, and keep Postgres off the keystroke path entirely."
• When scale arrives: "I'll grow the database in reversible steps: move table groups by logical replication with a pause of seconds, then shard big tables by colo, logical before physical, behind a query-routing proxy, and every move makes the old copy refuse writes permanently, in the database, not in a cache."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels

Sources

All sources used on this page, oldest first.

• Wallace, Rust in production at Figma, Figma blog, May 2, 2018.
• Wallace, How Figma's multiplayer technology works, Figma blog, October 16, 2019.
• Goel, Under the hood of Figma's infrastructure, Figma blog, November 21, 2019.
• Chen and Kim, GraphQL, meet LiveGraph: a real-time data system at scale, Figma blog, October 14, 2021.
• Tsung, Making multiplayer more reliable, Figma blog, October 20, 2022.
• Liang, The growing pains of database architecture, Figma blog, April 4, 2023.
• Steele, How Figma’s databases team lived to tell the scale, Figma blog, March 14, 2024.
• Bandi, Keeping it 100(x) with real-time data at scale, Figma blog, May 17, 2024.
• PostgreSQL documentation: Routine vacuuming, Vacuuming settings, Replication settings, Logical replication restrictions, CREATE VIEW, checked September 2026.
• PgBouncer, Usage (PAUSE, RESUME), checked September 2026.
• AWS documentation and pricing: Multi-AZ failover, RDS DB instance storage, Quotas for Amazon RDS, RDS CloudWatch metrics, Amazon RDS pricing, and the AWS Price List for RDS and S3 in us-west-2, checked September 2026.