Learning pathsA
GUIDED PRACTICE

Figma Multiplayer

Figma describes a centralized collaboration design inspired by CRDTs, not operational transformation.

Figma describes a centralized collaboration design inspired by CRDTs, not operational transformation. Its document contains objects and properties; the server resolves concurrent changes to the same property in arrival order. Independent properties can change without conflict. The published design also describes reconnecting clients fetching current state and reapplying offline edits. This is a dated account, not a claim about every current Figma feature. Source publication: 2019-10-16. The walkthrough below is an original interview exercise, not an undocumented claim about the company.

The mechanism at a glance

Client A → Local pending edits (optimistic edit); Local pending edits → Central authority (property update); Central authority → Property state (server order); Central authority → Client B (accepted value); Property state → Reconnect snapshot (latest snapshot); Reconnect snapshot → Client A (recover state)
Scroll to inspect the diagram, or open it at full size.

Figure — Client A → Local pending edits (optimistic edit); Local pending edits → Central authority (property update); Central authority → Property state (server order); Central authority → Client B (accepted value); Property state → Reconnect snapshot (latest snapshot); Reconnect snapshot → Client A (recover state)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. Choose a document model

In this independent whiteboard exercise, represent a shape by object ID and properties such as x, y and fill. A move changes position; a recolor changes fill. Compare this with text insertion, where positions shift after concurrent edits. Do not transfer a text-editor algorithm into a shape editor without identifying the actual operations.

2. Make conflicts visible

Assume A sets fill to blue while B sets fill to red. The authority chooses one final property value under its declared order. If A changes x while B changes fill, preserve both. Write this two-client table before drawing a cluster: the product semantics determine what the synchronization protocol must guarantee.

3. Separate responsiveness from acknowledgement

Apply a local edit immediately but retain its operation identity and acknowledgement state. A response from the server that predates a pending local edit must not cause unexplained flicker. The client needs a rule for pending versus acknowledged values, and a retry must not duplicate an operation.

4. Test reconnect and revocation

Disconnect A, change the document from B, then reconnect A with pending edits. Specify whether deleted objects can be recreated and how stale permissions are checked. A reconnect is not merely reopening a socket; it is reconciling document version, pending intent and authorization.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

Contract / pseudocode
object(id, parent_id, properties)
pending(client_id, operation_id, property, value)
accepted(document_id, server_sequence, operation_id)
Example: A changes shape.x; B changes shape.fill

Worked example

Original exercise: A moves shape S from x=10 to x=20 while B changes its fill from white to red. These operations affect different properties and should both survive. Next, have both set x to different values. Ask the learner to mark the conflict boundary and the authoritative winner. This exercise is intentionally about object properties, not merging two text strings.

Failure walkthrough

Original failure probe: an acknowledgement is lost, then the user reconnects after permission has been revoked. Retry deduplication cannot substitute for authorization. Check permission again, retain the local unsaved intent for user recovery, and reject the server mutation. A document snapshot must not grant continuing edit rights.

A edits x locally → B edits fill locally → Server accepts independent properties → Both clients reconcile acknowledgements → A reconnects with a pending edit
Scroll to inspect the diagram, or open it at full size.

Figure — A edits x locally → B edits fill locally → Server accepts independent properties → Both clients reconcile acknowledgements → A reconnects with a pending edit

Decisions and trade-offs

DecisionUseful whenCost to explain
Adopt the mechanismThe same workload constraint is demonstratedValidate with your own measurements
Keep a simpler designYour scale and guarantees are already metMonitor the trigger for changing it

Check your understanding

Why is a server-authoritative property map not the same as a decentralized text CRDT?

Show answer and explanation

Answer: The server supplies a conflict order and the atomic unit is a property value. A decentralized text CRDT must preserve character identities and convergence without relying on that central ordering authority. The data model and guarantees differ.

Primary documentation

Read the first-party engineering account or official technical reference. Company engineering posts describe the scope and date of that publication; the interview reconstruction and scenarios here are original teaching examples.

Continue the connection

Study Google Docs and explain which guarantee from this lesson carries into that topic.

6:00Self-guided practice timer
The timer resets when you leave this page. Save your design separately.
Your challenge

Why is a server-authoritative property map not the same as a decentralized text CRDT?

Your design draft

Clarify assumptions, explain your approach, and test the difficult cases. Save your draft, then compare it with the study notes.

Read study notes

Self-review checklist

Self-guided practice. Automated AI feedback and code execution are not connected.