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
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.
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.fillWorked 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.
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
| Decision | Useful when | Cost to explain |
|---|---|---|
| Adopt the mechanism | The same workload constraint is demonstrated | Validate with your own measurements |
| Keep a simpler design | Your scale and guarantees are already met | Monitor 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.