Making multiplayer more reliable | Figma Blog (opens in new tab)

Figma improved multiplayer reliability by adding a durable write-ahead journal alongside its existing checkpoint system. Instead of relying on full-file snapshots every 30–60 seconds, Figma now records incremental changes frequently, allowing crashed servers to recover nearly to the latest state and reducing deployment-related database spikes. The goal was to reduce potential data loss from up to 60 seconds to less than one second.

How Figma’s Multiplayer System Worked

• Browsers connect to Figma’s multiplayer service over WebSockets.
• The service authoritatively handles:
  • Validation
  • Ordering
  • Conflict resolution
  • Broadcasting updates to connected clients
• File state is held in memory for speed.
• Every 30–60 seconds, the entire file is:
  • Encoded into a binary format
  • Compressed
  • Uploaded to Amazon S3 as a checkpoint

Problems with Checkpoint-Only Persistence

• A multiplayer crash could lose up to 60 seconds of server-side work.
• Checkpoints become increasingly expensive as files grow in size and complexity.
• Redeployments caused large write spikes:
  • All in-memory files had to be closed.
  • Each file needed a final checkpoint.
  • The resulting burst increased database load.

Introducing the Journal

• Figma added a durable transaction log, or journal, backed by DynamoDB.
• Each accepted change receives an incrementing sequence number.
• Checkpoints store the latest sequence number they include.
• During recovery:
  • Multiplayer loads the latest checkpoint.
  • It queries the journal for entries with higher sequence numbers.
  • It replays those incremental changes to reconstruct the latest file state.
• Journal entries are much smaller than full-file checkpoints, since they contain only user edits.
• Figma writes journal data roughly every 0.5 seconds rather than waiting 60 seconds between full snapshots.
• The target was less than one second of data loss in rare failure scenarios.

Smoother Deployments

• During deployment, Figma can close connections and wait for unsaved changes to reach the journal.
• The 99th percentile persistence time is under one second.
• Since journal writes happen continuously during normal operation, deployments no longer create a sudden checkpoint-writing surge.
• Database write load is therefore steadier and more predictable.

Datastore and Batching Decisions

• Figma selected DynamoDB because the journal requires a horizontally scalable datastore with high write capacity.
• Postgres was considered but rejected because the anticipated write volume exceeded Figma’s current horizontal-scaling approach for Postgres.
• Clients send updates at approximately 30 frames per second, or every 33 milliseconds.
• The journal does not need that granularity, so multiple changes can be batched before being persisted, improving performance.

Figma’s approach combines inexpensive, frequent incremental journal writes with larger periodic checkpoints. This provides faster recovery, minimizes data loss, and avoids deployment-related load spikes while retaining checkpoints for efficient long-term storage and features such as version history.