Figma Multiplayer Editing.

How Do Two Hundred People Edit One Design File at the Same Moment Without Anyone's Work Disappearing?

It is 4 pm on a Thursday and the checkout redesign is in review. Priya, the designer who owns the file, nudges the "Pay" button 8 pixels left. In another city Arjun is changing the same button's colour. Meera is dragging the whole frame onto a new page. A hundred and fifty more people are in the file, watching, their cursors drifting across the canvas.

Every one of those screens has to end up showing the same file. Priya must see her nudge the instant she makes it, not a round trip later. Arjun's colour and Priya's nudge must both survive. And if the server holding this file dies halfway through the review, no edit anyone saw applied may disappear.

This is the system we'll design today.

The Interview Begins#

You're interviewing at a company building a collaborative design tool. The engineering lead shares her screen: one file, forty cursors moving, a sidebar listing a hundred and ninety people.

Your Questions#

Functional Requirements#

Non-Functional Requirements#

Traffic Estimation#

Presence Estimation#

Memory and Server Estimation#

Storage Estimation#

Key Metrics Summary#

System Architecture#

%% title: Multiplayer design tool architecture
flowchart TD
  subgraph L1["Layer 1 · Clients"]
    direction LR
    ED["Browser and desktop editors<br/>a local copy of the file"]:::client
    MOB["Mobile apps<br/>prototypes, comments"]:::client
  end
  subgraph L2["Layer 2 · Edge"]
    direction LR
    GW["WebSocket gateways<br/>TLS, session, route by file"]:::edge
    API["HTTP API + CDN<br/>file list, images, fonts"]:::edge
  end
  subgraph L3["Layer 3 · Control"]
    direction LR
    AUTH["Permissions<br/>role per file, revocations"]:::service
    RT[("Router + lock table<br/>file to owner, lock UUID")]:::store
  end
  subgraph L4["Layer 4 · Multiplayer (one authority per file)"]
    direction LR
    MP["Multiplayer server<br/>whole file in memory, sequences changes"]:::hot
    PR["Presence<br/>cursors and selections, memory only"]:::cache
  end
  subgraph L5["Layer 5 · Durability"]
    direction LR
    JR[("Journal<br/>changes in ~0.5 s batches")]:::store
    CK[("Checkpoints<br/>compressed file in blob storage")]:::store
    AS[("Asset store<br/>images by content hash")]:::store
  end
  subgraph L6["Layer 6 · Around the file"]
    direction LR
    VH["Version history<br/>autosaves, named versions"]:::service
    META[("Metadata database<br/>files, teams, comments")]:::store
  end
  L1 ==>|"changes, cursors"| L2
  L2 ==> L4
  L2 -.->|"on join: may this user edit?"| L3
  L4 ==>|"journal, checkpoints"| L5
  L5 -.-> L6

KEY INSIGHTS:

• One authority per file: the server that owns a file is the only place its order is decided; no consensus protocol runs per edit
• The file lives in memory there: checks and sequencing are memory operations, and storage is written behind them
• Cursors never touch storage: they share the connection but not the journal

Data Flow: One Nudge#

%% title: One nudge, from Priya to Arjun and into the journal
sequenceDiagram
  autonumber
  participant P as Priya's editor
  participant S as Multiplayer server
  participant J as Journal
  participant A as Arjun's editor
  Note over P: drags the Pay button 8 px left
  P->>P: Apply at once, x = 112, mark unacknowledged
  P->>S: change c41 · button.x = 112
  S->>S: May edit? Object exists? Sequence 9,012
  S-->>P: ack c41 = seq 9,012
  S-)A: seq 9,012 · button.x = 112
  A->>A: Apply, redraw on the next frame
  Note over S,J: every ~0.5 s
  S->>J: batch 9,001 to 9,040, only if the lock matches
  J-->>S: written
  S-)P: saved up to 9,040
  P->>P: Drop c41 from the outbox

MEANWHILE, IN PARALLEL:

• Priya's and Arjun's cursors stream both ways 20 times a second on the presence path, never written anywhere
• The 150 viewers receive seq 9,012 too; they can't send changes, so the server never has to check theirs

Deep Dive 1: The Data Model and Conflict Rules (Week 5 Concepts: Conflict Resolution)#

This builds on Week 5, Day 4 · Conflict Resolution: LWW registers, LWW-Maps, CRDT merge rules and the OT example.

What Figma has written: a document is "a two-level map: Map<ObjectID, Map<Property, Value>>"; its servers "keep track of the latest value that any client has sent for a given property on a given object", so "changes are atomic at the property value boundary". Figma "isn't using true CRDTs": with the server as central authority it can simplify, "inspired by multiple separate CRDTs". In Week 5's terms the document is an LWW-Map of LWW-Maps whose "timestamp" is the server's sequence number.

The tree: parent pointers and fractional indexing#

%% title: A file as a tree of objects
flowchart TD
  DOC["0:0 · Document"]:::core
  PG["1:2 · Page 'Checkout'<br/>parent 0:0 · pos 0.5"]:::service
  FR["17:9 · Frame 'Pay screen'<br/>parent 1:2 · pos 0.5"]:::service
  BT["17:204 · Button<br/>parent 17:9 · pos 0.25<br/>x 112 · fill coral"]:::hot
  TX["17:205 · Text 'Pay now'<br/>parent 17:9 · pos 0.5"]:::service
  IM["22:31 · Image<br/>parent 17:9 · pos 0.75<br/>asset by content hash"]:::service
  DOC --> PG --> FR
  FR -->|"children sorted by pos"| BT
  FR --> TX
  FR --> IM

• Object IDs carry the client: Figma assigns "every client a unique client ID" and includes it in new object IDs, so two clients can create objects offline without colliding (17:204 is client 17's 204th object).
• The parent is a property of the child. Moving a layer into another frame is one property write, with last-writer-wins like any other.
• Order among siblings is a fraction between 0 and 1; inserting between two siblings takes their average, so nothing else is renumbered. Figma stores arbitrary-precision fractions as base-95 strings, so precision never runs out.
• Same spot, same moment: if two inserts pick the same position, "the server can avoid ever having two objects with an identical position by just generating and assigning a unique position to the second insert operation". The two may interleave, which Figma notes is "usually fine" in a design.

Reparenting and cycles#

Meera drags frame A into frame B while Arjun drags frame B into frame A. Each move alone is fine; both together make A the parent of B and B the parent of A, a loop cut off from the document.

• The server refuses: Figma's servers "reject parent property updates that would cause a cycle". Whichever move arrives second is rejected, and its author's editor puts the layer back.
• Until the rejection arrives, a client may briefly hold a cycle (its own move plus the one it just received); Figma's client temporarily removes such objects from the tree until the server answers.
• Without a central server you would need a replicated-tree move algorithm, such as Kleppmann and colleagues' CRDT for moves in replicated trees. One authority makes it a single check.

# multiplayer/document.py

"""
One file's authority (illustrative). The whole file is in memory as
{object_id: {property: value}}. Changes are applied in arrival order and
each accepted one gets the next sequence number. Last writer wins per
property, where "last" means last to reach this server, never a clock.
"""

from dataclasses import dataclass, field
from fractions import Fraction
from typing import Any, Dict, Optional

ROOT = "0:0"


@dataclass
class Change:
    client_id: int
    change_id: int               # increasing per client: makes resends harmless
    obj: str                     # "client:counter", e.g. "17:204"
    props: Dict[str, Any]        # {"x": 112} or {"parent": "17:9", "pos": Fraction(1, 4)}
    create: bool = False


@dataclass
class Result:
    ok: bool
    seq: int = 0
    reason: str = ""
    server_values: Dict[str, Any] = field(default_factory=dict)   # for the client's rollback


class Document:
    def __init__(self, objects: Dict[str, Dict[str, Any]], seq: int):
        self.objects, self.seq = objects, seq
        self.applied: Dict[int, int] = {}            # client_id -> highest change_id applied

    def apply(self, ch: Change, can_edit: bool) -> Result:
        if not can_edit:
            return Result(False, reason="VIEW_ONLY")
        if ch.change_id <= self.applied.get(ch.client_id, 0):
            return Result(True, seq=self.seq, reason="DUPLICATE")   # resent after a reconnect
        obj = self.objects.get(ch.obj)
        if obj is None and not ch.create:
            return Result(False, reason="DELETED")                   # someone removed it first
        old = obj or {}
        parent = ch.props.get("parent", old.get("parent"))
        if obj is not None and "parent" in ch.props and self._inside(parent, ch.obj):
            return Result(False, reason="CYCLE", server_values={"parent": old.get("parent")})
        props = dict(ch.props)
        if "pos" in props:
            props["pos"] = self._free_pos(parent, ch.obj, props["pos"])
        self.objects.setdefault(ch.obj, {}).update(props)            # last writer wins, per property
        self.seq += 1
        self.applied[ch.client_id] = ch.change_id
        return Result(True, seq=self.seq, server_values=props)       # pos may have been moved

    def _inside(self, node: Optional[str], target: str) -> bool:
        """True if `node` is `target` or one of its descendants."""
        while node is not None and node != ROOT:
            if node == target:
                return True
            node = self.objects.get(node, {}).get("parent")
        return False

    def _free_pos(self, parent: str, me: str, pos: Fraction) -> Fraction:
        """A concurrent insert took this position: give this one the next free gap.
        (A real server keeps a sorted child list per parent instead of scanning.)"""
        taken = sorted(o["pos"] for k, o in self.objects.items()
                       if k != me and o.get("parent") == parent and "pos" in o)
        if pos in taken:
            later = [p for p in taken if p > pos]
            pos = between(pos, later[0] if later else Fraction(1))
        return pos


def between(a: Fraction, b: Fraction) -> Fraction:
    """Fractional indexing: a position strictly between two siblings."""
    return (a + b) / 2

Where the simple rule shows its edges:

• Text is one value. Figma's example: if one person changes a text layer "B" to "AB" and another to "BC", "the end result will be either AB or BC but never ABC". A product that needs merged typing would put a sequence CRDT (Week 5 Day 4's RGA) inside the text property only.
• Deletes need care. When an object is deleted, Figma keeps its properties in the undo buffer of the client that deleted it, not on the server. Undo re-creates it with the same ID; a later edit by someone else to a deleted ID is rejected.

Deep Dive 2: The Sync Protocol (Week 2 Concepts: Idempotency, Week 5: Consistency Models)#

The Solution:

%% title: The life of one local change
stateDiagram-v2
  [*] --> LOCAL: applied at once, sent
  LOCAL --> SEQUENCED: ack with seq
  LOCAL --> ROLLED_BACK: rejected, server value restored
  LOCAL --> LOCAL: reconnect, resent
  SEQUENCED --> SAVED: saved watermark passes seq
  SAVED --> [*]
  ROLLED_BACK --> [*]
  LOCAL: LOCAL · incoming values for its properties ignored
  SEQUENCED: SEQUENCED · ordered, kept and resent until saved
  SAVED: SAVED · in the journal, dropped from the outbox
  class LOCAL queue
  class SEQUENCED core
  class SAVED ok
  class ROLLED_BACK bad

• Two acknowledgements, not one (a design choice; Figma hasn't published its client protocol): "sequenced" ends the flicker rule for that property; "saved" (a watermark the server broadcasts after each journal write) lets the client forget the change.
• Idempotent resends: every change has a per-client change_id; the server drops any it has already applied (Week 2's idempotency keys, applied to edits).

# client/sync.py

"""
The client's half of the protocol (illustrative). Local edits apply at once.
A property with an unacknowledged local change ignores incoming values, so
the screen never flickers. Changes stay in the outbox until the server says
they are saved, so a server crash cannot lose them.
"""

from typing import Dict, Tuple

from protocol import Change      # the same dataclass the server uses


class Sync:
    def __init__(self, doc, ws, client_id: int):
        self.doc, self.ws, self.client_id = doc, ws, client_id
        self.next_id = 1
        self.unacked: Dict[Tuple[str, str], int] = {}   # (obj, prop) -> newest change_id
        self.outbox: Dict[int, Change] = {}             # change_id -> change, until saved
        self.seq_of: Dict[int, int] = {}                # change_id -> server seq, once acked
        self.last_seq = 0                               # newest server seq applied here
        self.epoch = ""                                 # owner's lock UUID that issued last_seq

    def edit(self, obj: str, props: dict) -> None:
        ch = Change(self.client_id, self.next_id, obj, props)
        self.next_id += 1
        self.doc.set(obj, props)                        # optimistic: on screen this frame
        for p in props:
            self.unacked[(obj, p)] = ch.change_id
        self.outbox[ch.change_id] = ch
        self.ws.send(ch)

    def on_remote(self, seq: int, obj: str, props: dict) -> None:
        self.last_seq = seq
        theirs = {p: v for p, v in props.items() if (obj, p) not in self.unacked}
        self.doc.set(obj, theirs)                       # our pending value will win anyway

    def on_ack(self, change_id: int, seq: int, server_values: dict) -> None:
        self.seq_of[change_id] = seq
        self.last_seq = max(self.last_seq, seq)
        self._settle(self.outbox[change_id], server_values)    # e.g. a pos the server moved

    def on_reject(self, change_id: int, reason: str, server_values: dict) -> None:
        ch = self.outbox.pop(change_id)
        if reason == "DELETED":
            self.doc.remove(ch.obj)
        self._settle(ch, server_values)                          # roll back to the truth

    def _settle(self, ch, server_values: dict) -> None:
        for p in ch.props:
            if self.unacked.get((ch.obj, p)) == ch.change_id:    # no newer local edit to it
                del self.unacked[(ch.obj, p)]
                if p in server_values:
                    self.doc.set(ch.obj, {p: server_values[p]})

    def on_saved(self, saved_seq: int) -> None:
        for cid in [c for c, s in self.seq_of.items() if s <= saved_seq]:
            self.outbox.pop(cid, None)
            del self.seq_of[cid]

    def on_reconnect(self, ws) -> None:
        self.ws = ws
        ws.send({"hello": True, "epoch": self.epoch, "last_seq": self.last_seq})   # catch me up
        for ch in sorted(self.outbox.values(), key=lambda c: c.change_id):
            for p in ch.props:
                self.unacked.setdefault((ch.obj, p), ch.change_id)
            ws.send(ch)                                       # duplicates are dropped by change_id

Reconnect and catch-up#

When a laptop wakes up or a train leaves a tunnel, the client reconnects with the last sequence number it applied:

Deep Dive 3: Presence and Cursors at Fan-Out (Week 3 Concepts: Backpressure and Flow Control)#

The Challenge:

The Solution:

%% title: Cursors on their own path
flowchart TD
  IN(["Cursor moves<br/>client sends at most 20 a second"]):::client
  subgraph MP["Multiplayer server · presence, in memory only"]
    direction TB
    LAST[("Latest position per session<br/>overwritten, never appended")]:::cache
    TICK["Tick every 50 ms<br/>every 100 ms above 50 cursors"]:::core
    PICK{"Moved, among the 200 shown,<br/>inside this viewer's viewport?"}:::service
  end
  SEND(["One frame per viewer<br/>~12 bytes per cursor"]):::ok
  SKIP(["Socket backed up: skip<br/>the next frame is newer"]):::bad
  IN --> LAST --> TICK --> PICK
  PICK -->|"yes, socket keeping up"| SEND
  PICK -->|"socket backed up"| SKIP

• Keep only the newest: each session's latest position overwrites the last; a tick sends every viewer one frame with the shown cursors that moved inside its viewport.
• Never queue behind a slow reader: a socket with ~32 KB unsent skips the frame; once a second a keyframe carries every shown cursor, so a skipped frame can't leave one stuck.
• Figma's own limit caps visible cursors at 200; beyond that, extra cursors aren't shown to others, and editors' cursors take priority over viewers'.
• Selections, avatars and follow mode (watching a presenter's viewport) ride the same path: each is one more coalesced value.

Deep Dive 4: Persistence, Durability and One Owner per File (Week 5 Concepts: Leader Election and Fencing, Week 3: Audit Log)#

What Figma has written: before 2022, multiplayer wrote each file to S3 "every 30 to 60 seconds" as a checkpoint, so a crash could lose "up to 60 seconds of work on the server-side". The journal records each change with a per-file sequence number, writes "every 0.5 seconds vs. every 60 seconds", and on recovery multiplayer loads the checkpoint and "queries for all entries that are newer". To avoid split brain, "multiplayer writes a (lock UUID, file key) entry to take ownership of that file", and journal writes are conditional on the lock UUID matching. The journal handles more than 2.2 billion changes a day, and 95% of edits are saved within 600 ms.

# multiplayer/durability.py

"""
Ownership and the journal for one file (illustrative). Every journal write
is conditional on this server still holding the file's lock, so a server
that lost ownership cannot write (fencing).
"""

import asyncio
import uuid

FLUSH_S = 0.5                    # journal batch interval


class LostOwnership(Exception):
    pass


class Owner:
    def __init__(self, file_key: str, kv, blobs):
        self.file_key, self.kv, self.blobs = file_key, kv, blobs
        self.lock = uuid.uuid4().hex
        self.buffer = []                          # accepted changes not yet journalled
        self.saved_seq = 0

    def open(self):
        self.kv.put("locks", self.file_key, {"lock": self.lock})        # the router chose us
        ck = self.kv.get("checkpoints", self.file_key)                  # {seq, blob_key}
        doc = Document.decode(self.blobs.get(ck["blob_key"]), seq=ck["seq"])   # slow for huge files
        for batch in self.kv.query("journal", self.file_key, after=ck["seq"]):
            doc.replay(batch)                                           # skips seq <= doc.seq; restores change_ids
        self.saved_seq = doc.seq
        return doc

    def _fenced(self):
        return ("locks", self.file_key, {"lock": self.lock})

    async def flush_loop(self, doc, broadcast_saved) -> None:
        while True:
            await asyncio.sleep(FLUSH_S)
            if self.buffer:
                batch, self.buffer = self.buffer, []
                ok = self.kv.put_if("journal", self.file_key,
                                    {"start": batch[0].seq, "end": batch[-1].seq, "changes": batch},
                                    condition=self._fenced())
                if not ok:
                    raise LostOwnership(self.file_key)    # stop serving; clients go to the new owner
                self.saved_seq = batch[-1].seq
                broadcast_saved(self.saved_seq)           # clients drop these from their outboxes
            # every 10 minutes or 5,000 changes: upload doc.encode() to blob storage and
            # point the file's checkpoint at it with the same lock condition

A few details carry the correctness:

• The journal decides durability; checkpoints decide recovery time. So checkpoints can go from every minute to every ten (every 10 minutes or 5,000 changes here): uploads drop from ~27 Gbps to ~2.7 Gbps and nothing is less safe.
• A checkpoint may run a little ahead of the journal. That's safe: both come from the same owner's order, recovery replays only changes after the checkpoint's sequence number, and resent changes it already holds are dropped as duplicates. The blob can be uploaded anywhere; the pointer to it is fenced.
• Version history is a different "checkpoint". Figma's user-facing autosave (every 30 minutes) is an entry in the version history, kept for the plan's retention; the engineering checkpoint above is a recovery snapshot. Keep the words apart in the interview.

Routing every user of a file to its one owner#

• The router maps file → owner. On the first open it picks a server with spare memory; the server takes the lock and loads the file. Gateways ask the router once per session and cache the answer.
• Wrong server? If a gateway's cached route is stale, the server that doesn't hold the lock answers "moved", and the gateway asks again. A server never serves a file whose lock it doesn't hold.
• When the last person leaves, the server flushes, checkpoints and unloads the file after a few idle minutes, freeing memory for the next one.

Moving a hot or draining file#

Figma has written that on a multiplayer deploy, closing connections and waiting for unsaved changes to reach the journal takes under 1 second at the 99th percentile. Moving a big, busy file needs one more idea: warm the new owner before the old one lets go.

%% title: Moving one file off a draining host
sequenceDiagram
  autonumber
  participant C as Editors in the file
  participant O as Old owner
  participant R as Router and lock table
  participant N as New owner
  participant J as Journal
  R->>N: Prepare file F
  N->>J: Load checkpoint, follow the journal
  Note over N: decoding done before the cutover
  R->>O: Hand F to N
  O->>O: Stop sequencing, new changes stay in clients' outboxes
  O->>J: Flush the last batch, up to seq 9,412
  O-->>R: Flushed up to 9,412
  R->>R: Lock F with N's UUID, route F to N
  N->>J: Read the final batches up to 9,412
  O-)C: Moved: reconnect to N, jittered over 2 s
  C->>N: Hello, last seq 9,412, then the outbox
  N-->>C: Nothing missed, acks for the resent changes
  Note over O,J: any late write from O fails the lock check

Deep Dive 5: Offline Editing, Huge Files, Comments and Branches (Week 5 Concepts: Conflict Resolution, Week 4: Caching)#

Huge files: send the page, not the file#

Figma's 2024 post on dynamic page loading shows the shape of the answer: load "the first page and all of its read and write dependencies" and fetch other pages on demand. Read dependencies are things the page renders from elsewhere (components, styles, variables); write dependencies are objects an edit here would change automatically (auto layout, for example). The multiplayer server "holds both the full representation of the file and the QueryGraph of dependencies in-memory", and decides which edits each session needs.

• The client subscribes to pages, and the server filters the edit stream per session: a change on a page nobody in the session has loaded isn't sent to them.
• The server still holds everything, so permission checks, cycle checks and dependency updates always see the whole file. That's why our memory estimate counts full files.
• Images and fonts never sit in the document: objects hold a content hash; the bytes live in the asset store behind a CDN and are fetched as the page is drawn (Week 4's caching tiers).

Comments and branches#

• Comments aren't document objects. Figma's LiveGraph post lists comments among the features its real-time layer over Postgres serves. A comment stores the layer's ID, so deleting the layer orphans it rather than corrupting the file.
• A branch is a regular file, multiplayer included (Figma's branching post). On merge, Figma's help centre calls it a conflict when an element you changed "has been updated in the main file"; the user picks the main file's version or the branch's.

A File's Day#

Edge Cases#

Monitoring Dashboard#

SLOs for the Platform#

The interviewer drags a new window over the first. "One more."

Summary: Concepts Applied from 10-Week Course#

Why Figma Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

Data model:

Sync and presence:

Durability and operations:

Sources#

Figma engineering blog:

• Blog

  Evan Wallace — How Figma's multiplayer technology works (two-level map, per-property last-writer-wins, "isn't using true CRDTs", unacknowledged changes, client IDs in object IDs, parent links, cycle rejection, fractional indexing, undo rule, offline replay), October 2019: https://www.figma.com/blog/how-figmas-multiplayer-technology-works/

• Blog

  Darren Tsung — Making multiplayer more reliable (checkpoints every 30-60 s to S3, journal in DynamoDB every 0.5 s, sequence numbers, lock UUID, 2.2 billion+ changes a day, 95% saved within 600 ms, deploy flush under 1 s at p99), October 2022: https://www.figma.com/blog/making-multiplayer-more-reliable/

• Blog

  Evan Wallace — Realtime editing of ordered sequences (fractional indexing, base-95 strings, server assigns unique positions, interleaving), March 2017: https://www.figma.com/blog/realtime-editing-of-ordered-sequences/

• Blog

  Evan Wallace — Rust in production at Figma (multiplayer server, one process per document), May 2018: https://www.figma.com/blog/rust-in-production-at-figma/

• Blog

  Isaac Goldberg and Naomi Jung — Speeding up file load times, one page at a time (dynamic page loading, QueryGraph, 33% / 70% / 33%, parallel decoding), May 2024: https://www.figma.com/blog/speeding-up-file-load-times-one-page-at-a-time/

• Blog

  John Fuetsch — How (and why) we built branching, October 2021: https://www.figma.com/blog/how-and-why-we-built-branching/

• Blog

  Rudi Chen and Slava Kim — GraphQL, meet LiveGraph: a real-time data system at scale (comments and the file browser over Postgres), October 2021: https://www.figma.com/blog/livegraph-real-time-data-fetching-at-figma/

Figma help centre:

• Blog

  How many people can be in a file at once? (500 people, 200 editing, 200 cursors): https://help.figma.com/hc/en-us/articles/1500006775761

• Blog

  View a file's version history (a checkpoint every 30 minutes, autosaves on connection loss): https://help.figma.com/hc/en-us/articles/360038006754

• Blog

  Get updates from main files (branch conflicts): https://help.figma.com/hc/en-us/articles/5665728006423

Company filings and press:

• Read

  Figma, Inc. — Form S-1, July 2025 (13 million+ monthly active users, two-thirds non-designers, ~450,000 paid customers, $749.0 million revenue in 2024, users "often for hours a day"): https://www.sec.gov/Archives/edgar/data/1579878/000162828025033742/figma-sx1.htm

• Paper

  Figma — Q1 2026 earnings prepared remarks (~690,000 paid customers as of 31 March 2026, up from ~450,000), May 2026: https://s206.q4cdn.com/973901332/files/doc_financials/2026/q1/Figma-Q1-2026-Prepared-Remarks.pdf

• Read

  Fortune — Figma files for its IPO, July 2025: https://fortune.com/2025/07/02/figma-ipo-s-1-filing-growth-profitability-dual-class-share-structure-dylan-field-nyse-fig

Research:

• Docs

  Marc Shapiro, Nuno Preguiça, Carlos Baquero, Marek Zawirski — Conflict-free Replicated Data Types, SSS 2011 (LNCS 6976): https://doi.org/10.1007/978-3-642-24550-3_29

• Paper

  Martin Kleppmann, Dominic P. Mulligan, Victor B. F. Gomes, Alastair R. Beresford — A highly-available move operation for replicated trees, IEEE TPDS, 2021: https://martin.kleppmann.com/papers/move-op.pdf

Design note: the architecture, code, thresholds, rates, sizes and dashboards here are an illustrative design for the problem, not a description of Figma's internal systems beyond what Figma has published.

Further Reading#

Related systems to study:

• Read

  WhatsApp (Bonus Problem 2 in this series): per-conversation ordering and offline delivery

• Read

  Zerodha Kite (Bonus Problem 13): lossy fan-out of snapshots beside a lossless event stream

• Read

  Twitter / X (Bonus Problem 10): fan-out at scale

Foundational concepts (this course):

• Read

  Week 5, Day 4 — Conflict Resolution

• Read

  Week 5, Day 5 — Leader Election

• Read

  Week 5, Day 1 — Consistency Models

• Read

  Week 2, Day 2 — Idempotency in Practice

• Read

  Week 3, Day 3 — Backpressure and Flow Control

• Read

  Week 10, Day 3 — Deployment Strategies

"Two hundred people can edit one file because only one machine decides what it looks like, and it writes that decision down every half second."