Design a collaborative design tool like Figma

Requirements: scoping a design tool

"Build Figma" is really four products in one box: a drawing engine, an editor with tools and panels, a sync engine for many people, and a platform for plugins and export. An hour is not enough for all four, so the first five minutes go to questions whose answers change the design. Ask about size first, because size decides how you render and how you find things under the pointer. Then ask how live collaboration must be, and what a file can contain.

The table lists the questions in the order a senior engineer would ask them, the answer this guide assumes, and what part of the design moves if the answer is different. Write the assumed answers on the board. Every later number in the design comes from them.

Functional requirements

• Open a file and see the current page drawn within about 3 s, even when the file is large.
• Pan and zoom an infinite canvas from about 1% to several thousand percent, with the drawing staying sharp at every level.
• Create shapes, text, and frames with tools; select, move, resize, rotate, and reorder them with the mouse, touch, or keyboard.
• Group layers, nest frames, and set constraints so children react when a parent frame is resized.
• Make a component and place instances of it; change the component and see every instance update, while keeping each instance's overrides.
• See other editors' cursors, names, and selections live, and their edits within about 200 ms.
• Undo and redo your own changes, without undoing other people's work.
• Use a layers panel (the tree of everything on the page) and a properties panel (position, size, fill, stroke, text style) for precise edits.
• Run plugins, and export any layer to PNG, SVG, or PDF.

Non-functional requirements

• Frame budget: pan, zoom, and drag at 60 fps. A dropped frame while dragging feels like the shape is sticky.
• Input latency: a dragged shape follows the pointer in the next frame, under about 20 ms from event to pixels. Hover highlight must also land in the same frame.
• Memory: stay under about 1.5 GB for a 50,000 layer file, so the tab is not killed on an 8 GB laptop.
• No lost work: every change reaches the server within a second or two, survives a reload, and is never silently overwritten.
• Correct merging: two people editing the same file always end up seeing the same document.
• Security: a plugin or a shared file must never run code with the user's session.
• Accessibility: every command reachable by keyboard, and the layers and properties panels usable with a screen reader. The canvas itself has real limits here, and we will be honest about them.

Out of scope, and why

• Prototyping and animation playback: a separate viewer with its own runtime. Mention it, then park it.
• Code generation for developers (Dev Mode): it reads the same document, so it adds no new design problems.
• Server storage and the file format on disk: we treat the server as a box that stores files and relays changes, and only design what the client needs from it.
• Comments: same anchoring problem as comments in a text editor, but pinned to a canvas point or a node. One sentence is enough.

What makes a design tool hard

Most web apps show lists of things that the browser lays out for you. A design tool is the opposite: the app owns every pixel, every hit test, and every drag, because the browser's layout engine doesn't know what a rotated vector path with a blur is. Five properties of the problem drive every later decision. Keep them in mind; each chapter answers one of them.

1. Huge and free form. A page is an endless plane with tens of thousands of layers, at any position, rotation, and zoom. Nothing is in a neat list, so nothing comes for free from the DOM. You need your own renderer and your own way of finding what is under the pointer.
2. Continuous interaction. People drag, resize, and zoom constantly. A drag produces a pointer event every 4 to 16 ms, and each one must update the shape, the snapping guides, the properties panel, and the screen inside one frame. A page that is merely "fast enough to load" is not enough; every frame must be fast.
3. Deeply nested and linked. Layers live inside frames inside other frames. Components link instances across the whole file, so changing one master can change 3,000 layers. One edit can ripple far from where it was made.
4. Many writers, no locks. Five people can drag, recolor, and delete the same things at the same moment. Everyone must end with the same file, nobody's work may vanish silently, and your own edits must never wait for the network.
5. Untrusted code inside. Plugins written by strangers read and change the document. They must be powerful enough to be useful and boxed in enough to be safe.

The wireframe above names the parts of the screen we are designing: the toolbar across the top, the layers panel on the left, the canvas in the middle with other people's cursors on it, and the properties panel on the right. Only the canvas is drawn by our own renderer. The panels are normal DOM built with React, which matters later for accessibility and for how state flows between the two worlds.

Two worlds on one page

It helps to see the app as two programs sharing one document. The canvas engine owns the scene graph, draws it on the GPU, and answers "what is under this point?". The UI shell is ordinary React: menus, panels, dialogs, and inputs.

They talk through a narrow bridge: the engine publishes "selection changed" and "properties of the selected nodes are now X", and the shell sends commands like "set fill of node 12:7 to red". Keeping this boundary narrow is what lets the engine be fast (no React re-render per frame) and the shell be accessible (real buttons and inputs).

The scene graph: modelling the document

Everything else sits on the document model, so we design it first. The naive model is a flat array of shapes, each with absolute x, y, width, and height. It renders easily and fails the moment someone makes a frame.

Move the frame and you must find and move all 400 shapes "inside" it, and you don't even know which ones are inside, because nothing records it. Rotate a group and every child needs new coordinates. Make a component and you have no way to say "these 30 shapes are one thing, used 200 times".

Design tools use a scene graph: a tree of nodes where each node is a layer, its children are the layers inside it, and each node's position is stored relative to its parent. The root is the document, its children are pages, a page's children are top level frames and shapes, and so on down. Move a frame and you change one number; the children move with it because their positions are relative.

Node types and their properties

Every visible node also shares a common set of properties: name, visible, locked, opacity, blendMode, fills, strokes, effects (shadows and blurs), a transform, a size, and constraints. Fills are a list, not one color, because a layer can stack a solid color, a gradient, and an image.

Transforms: local and world

Each node stores a relative transform: a 2 by 3 affine matrix that maps the node's own coordinates into its parent's. An affine matrix holds translation, rotation, scale, and skew in six numbers [a, b, c, d, tx, ty].

To draw a node or test a click against it, you need its world transform: the product of every matrix from the page down to the node. Multiplying 6 to 10 matrices per node per frame for 50,000 nodes is wasteful, so the engine caches each node's world transform and world bounding box, and marks them dirty when the node or any ancestor changes.

type Mat = [a: number, b: number, c: number, d: number, tx: number, ty: number];

function multiply(p: Mat, c: Mat): Mat {
  return [
    p[0] * c[0] + p[2] * c[1], p[1] * c[0] + p[3] * c[1],
    p[0] * c[2] + p[2] * c[3], p[1] * c[2] + p[3] * c[3],
    p[0] * c[4] + p[2] * c[5] + p[4], p[1] * c[4] + p[3] * c[5] + p[5],
  ];
}

function worldTransform(node: SceneNode): Mat {
  if (!node.worldDirty) return node.worldCache;
  const parent = node.parent;
  node.worldCache = parent ? multiply(worldTransform(parent), node.transform) : node.transform;
  node.worldDirty = false;
  return node.worldCache;
}

// Moving a frame marks its whole subtree dirty; nothing is recomputed until it is drawn or hit tested.
function markDirty(node: SceneNode) {
  node.worldDirty = true;
  for (const child of node.children) markDirty(child);
}

A worked example: a frame sits at (100, 50) on the page. Inside it, a rectangle sits at (20, 10) and is rotated 90 degrees. The rectangle's world transform is the frame's translation times the rectangle's own translate and rotate, so its top left corner lands at (120, 60) on the page and its width now points straight down.

Drag the frame 30 units right and only the frame's tx changes from 100 to 130. The rectangle's stored numbers don't change at all, which also means a collaborator who is recoloring the rectangle at the same moment never conflicts with you.

Constraints: what children do when a frame resizes

Relative positions solve moving, not resizing. When someone makes a 375 wide phone frame 414 wide, a button pinned to the right edge should stay pinned. Each child has constraints per axis: MIN (keep the distance to the left or top edge), MAX (keep the distance to the right or bottom), STRETCH (keep both, so the child grows), CENTER, and SCALE (keep the proportion).

On a resize, the engine applies them to each direct child and writes the new transforms and sizes. Those writes are ordinary property changes, so they sync to other people like any other edit. Auto layout frames go one step further and position children like CSS flexbox: direction, gap, padding, and alignment.

Storing the tree: nested or flat?

type NodeId = string; // "sessionId:counter", for example "42:1093"

type SceneNode = {
  id: NodeId;
  type: "FRAME" | "GROUP" | "RECTANGLE" | "ELLIPSE" | "VECTOR" | "TEXT" | "COMPONENT" | "INSTANCE";
  // one property, so a move updates parent and place together
  parentIndex: { parentId: NodeId; position: string }; // position: fractional index, "a0", "a0V"...
  name: string;
  visible: boolean;
  locked: boolean;
  transform: Mat;              // relative to the parent
  size: { w: number; h: number };
  fills: Paint[];
  strokes: Paint[];
  effects: Effect[];
  constraints: { h: Constraint; v: Constraint };
  // type specific: characters and style runs for TEXT, componentId and overrides for INSTANCE...
};

type Document = Map<NodeId, SceneNode>;

Rendering: drawing 50,000 layers at 60 fps

We have a tree of nodes. Now we must turn it into pixels, again and again, while the user pans and zooms. The naive renderer uses the Canvas 2D API and, on every frame, clears the canvas and draws every node on the page with fillRect, fill(path), and fillText.

For a 300 layer mockup that works. For the 50,000 layer design system file it fails: even at a cheap 20 microseconds per simple shape, 50,000 shapes cost a full second per frame, and shapes with shadows, blurs, and image fills cost much more. Panning becomes a slideshow.

Two separate ideas fix this, and it pays to keep them apart in the interview. One is which drawing API to use. The other is how little work to do per frame: draw only what is visible, only what changed, and reuse what was drawn last time. The second idea matters more than the first, but both are needed at this size.

Choosing a drawing API

The camera: pan and zoom as one matrix

The canvas element never moves. Instead, a camera says which part of the infinite page is visible: an x and y in page coordinates at the top left of the screen, and a zoom.

Every node's world transform is multiplied by the camera matrix to get screen pixels, then by devicePixelRatio so the drawing is sharp on a retina screen (the canvas backing store is 2 or 3 times the CSS size). Panning changes x and y; zooming changes zoom and moves x and y so the point under the cursor stays still, which is what makes a pinch zoom feel anchored.

type Camera = { x: number; y: number; zoom: number }; // x, y: page point at screen top left

const toPage = (cam: Camera, sx: number, sy: number) => ({
  x: cam.x + sx / cam.zoom,
  y: cam.y + sy / cam.zoom,
});

function zoomAt(cam: Camera, sx: number, sy: number, factor: number): Camera {
  const zoom = Math.min(256, Math.max(0.01, cam.zoom * factor));
  const anchor = toPage(cam, sx, sy);
  return { zoom, x: anchor.x - sx / zoom, y: anchor.y - sy / zoom };
}

canvas.addEventListener("wheel", (e) => {
  e.preventDefault(); // needs { passive: false }
  if (e.ctrlKey) camera = zoomAt(camera, e.offsetX, e.offsetY, Math.exp(-e.deltaY * 0.01));
  else camera = { ...camera, x: camera.x + e.deltaX / camera.zoom, y: camera.y + e.deltaY / camera.zoom };
  requestFrame();
}, { passive: false });

On trackpads, Chromium and Firefox report a pinch as a wheel event with ctrlKey set to true, which is why the code checks it. Safari on macOS also fires its own non-standard gesturestart, gesturechange, and gestureend events with a scale value, so canvas apps usually handle those too. Note the { passive: false }: without it the browser may scroll or zoom the whole page before our handler can call preventDefault().

Doing less work per frame

1. Render on demand. Run a requestAnimationFrame loop only while something is dirty: the camera moved, a node changed, or an image finished loading. An idle editor draws nothing and uses no battery.
2. Cull. Ask the spatial index (next chapter) which nodes' world bounds overlap the visible rectangle. At 100% zoom on a big file, that is usually a few hundred of the 50,000 nodes. Skip the rest without touching them.
3. Skip detail that can't be seen. At 5% zoom a 12 px label is less than a pixel tall. Draw it as a grey bar, or not at all. Draw images from a smaller, pre-scaled version (a mipmap) instead of the 4,000 px original.
4. Cache in tiles. Rasterize the page into square tiles (for example 512 by 512 device pixels) at the current zoom and keep them as GPU textures. A pan then mostly copies existing tiles to new screen positions and renders only the strip of tiles that just came into view.
5. Redraw dirty rectangles only. When one shape changes, mark the union of its old and new bounds as dirty, and re-render only the tiles that rectangle touches. Moving a 40 px icon redraws one or two tiles, not the screen.
6. Batch. Group shapes that use the same shader and texture into one draw call. The GPU is fast at drawing; what is slow is the number of separate calls and state changes.

Zoom is the hard case for tiles, because every cached tile is now the wrong resolution. The usual trick: during the gesture, stretch the existing tiles (they look slightly soft for a moment), and when the zoom settles for about 100 to 200 ms, re-render the visible tiles at the new resolution, nearest to the center first. Users accept a brief blur; they do not accept a stutter. Keep the tile cache inside a budget (say 256 MB of textures) and evict the least recently used tiles first.

Text on a GPU canvas

WebGL has no fillText. A design tool also needs the same line breaks on every machine and in every export, which browser text layout does not promise. So the engine owns text: it loads font files, shapes the characters into positioned glyphs (a shaping library such as HarfBuzz, compiled to WebAssembly, handles ligatures, kerning, and scripts like Arabic and Devanagari), breaks lines itself, and draws glyphs either as vector outlines or from a cached glyph atlas texture.

A cheaper first version draws each text node with Canvas 2D fillText into an offscreen texture and uploads it, accepting small differences between machines. Editing text in place is a different story: the editing internals (caret, selection, and composition through an IME, the input method editor used to type languages such as Japanese and Chinese) are covered in the rich text editor guide, and a common shortcut is to place a transparent DOM text field over the node while it is being edited.

When the GPU goes away

The browser can take the GPU context away at any time: a driver crash, too many tabs using WebGL, or the laptop switching graphics cards. The canvas fires webglcontextlost, and every texture and buffer is gone.

Because the scene graph is the source of truth and tiles are only a cache, recovery is simple: call preventDefault() on the event so the browser will try to restore the context, then on webglcontextrestored rebuild shaders and buffers and redraw. If the renderer kept the only copy of anything on the GPU, that would be lost work.

Hit testing and selection: what is under the pointer?

With a DOM, the browser tells you which element was clicked. On our canvas, a click is just an (x, y) in screen pixels, and we must answer "which layer is that?" ourselves.

We ask it far more often than on clicks: every pointermove updates the hover outline, so the question runs 60 to 120 times a second while the mouse moves. The answer must be correct (a thin diagonal line, a ring with a hole, a rotated star) and it must take well under a millisecond, because it shares the frame with drawing.

The naive answer loops over every node from the topmost down, converts the point into the node's local space, and runs an exact geometry test. On 50,000 nodes with real path tests, that costs several milliseconds per move, and more for vector paths with hundreds of curve segments. The fix is the same idea the renderer uses: don't look at things that can't possibly match. Split the work into two phases.

1. Broad phase: a spatial index returns the few nodes whose world bounding box contains the point. Cheap, approximate, and usually 1 to 10 candidates.
2. Narrow phase: for each candidate, from top of the z-order down, run the exact test. Transform the point by the inverse of the node's world matrix, then test the real shape: corner radius rectangle, ellipse equation, or a path winding test for vectors, with the stroke width added. The first hit wins.

Choosing a spatial index

Play with the lab above. With a linear scan, the number of checks equals the number of shapes no matter where you point. With a grid, it drops to the shapes in one cell. Now crowd the shapes into one corner: the busy cell fills up and its count rises, which is exactly why an adaptive structure like an R-tree is the safer choice for real files.

Picking rules: which layer does a click mean?

Finding every node under the point is not the end. Design tools pick by rules that feel natural to designers, and you should mention them because they change what the hit test returns:

• Topmost wins: the narrow phase walks candidates in reverse paint order, so what you see on top is what you get.
• Context matters: a single click on a shape inside a group selects the group. A double click enters the group and selects the shape. A modifier (Cmd on macOS, Ctrl on Windows) selects the deepest layer directly.
• Skip what can't be picked: hidden and locked layers are ignored. A top level frame works like an artboard: clicking its name label selects it, while a drag on its empty area usually starts a marquee instead of moving the whole frame.
• Tolerance in screen pixels: a 1 unit line at 25% zoom is a quarter of a pixel wide. Add a tolerance of about 4 screen pixels, converted to page units by dividing by zoom, so thin lines stay clickable at any zoom.

Marquee selection and handles

Dragging on empty canvas draws a marquee rectangle. It becomes a rectangle query on the same index, then a narrow phase that checks whether each candidate's actual shape intersects the box. Tools differ on whether touching is enough or full containment is required; pick one, and make it consistent. Selection with Shift adds or removes nodes.

Once something is selected, the engine draws a selection box with eight resize handles and invisible rotation zones just outside each corner. Handles are tested before any layer, and in screen space: an 8 by 8 pixel handle stays 8 pixels at every zoom. That ordering matters. If layers were tested first, a small shape under a handle would steal the click, and resizing tiny icons would be impossible.

Editing interactions: drag, snap, resize, nudge

Selection tells us what the user is pointing at. Now they press and move. A drag in a design tool looks simple and hides most of the editor's subtle bugs: drift, jitter, lost pointers, a hundred undo steps for one move, and collaborators seeing a shape teleport. The cure is to treat each gesture as a small state machine with a clear start, a stream of previews, and one commit or cancel at the end.

Walk through the machine. On pointerdown the tool hit tests handles first, then layers, then empty canvas, and enters pressing with a note of what was hit. Nothing moves yet: a click and a drag start the same way.

Only when the pointer travels more than about 3 screen pixels does the machine enter dragging, resizing, rotating, or marquee. That threshold is what stops a slightly shaky click from nudging a shape by one pixel. pointerup commits; Escape or pointercancel puts every node back where it started.

Pointer events done right

• One event model. Pointer events cover mouse, touch, and pen with the same handlers. Set touch-action: none on the canvas so the browser doesn't turn a finger drag into page scrolling.
• Pointer capture. Call canvas.setPointerCapture(e.pointerId) on pointerdown. All later moves for that pointer come to the canvas even when the pointer leaves it or crosses a panel, and pointerup is never lost outside the window.
• Absolute, not incremental. At drag start, save each selected node's start transform and the start point in page coordinates. On each move compute delta = (current - start) / zoom and set transform = start + delta. Adding small deltas move by move accumulates rounding error and drifts away from the cursor.
• One update per frame. Pointer moves can arrive faster than the display refreshes. Store the latest position and apply it in the next requestAnimationFrame. For the pen tool, read e.getCoalescedEvents() to get every intermediate point for a smooth curve.

The sequence shows a drag end to end. The local document changes on every frame, so the shape follows the pointer with no network wait. Collaborators also see the shape slide rather than jump, because the client sends the in-progress transform about every 50 ms.

Only the final value at pointerup becomes one undo step. If the server rejects the change (for example the user's edit access was just removed), the client rolls the node back to the server's value and shows a message.

Snapping and smart guides

Designers expect a dragged box to click into line with its neighbours. Snapping means: if an edge or the center of the moving selection is within a few pixels of an edge or center of another layer, shift the selection so they line up exactly, and draw a red guide line with the distance. The naive version compares the moving box with every node on the page on every move. The fast version prepares once, at drag start:

1. Query the spatial index for nodes visible in the viewport, excluding the ones being dragged. Usually 50 to 300 nodes.
2. Collect their snap lines: left, center, and right x values, and top, middle, and bottom y values, plus the parent frame's edges and the layout grid. Sort each list.
3. On each move, take the dragged box's three x values and three y values, and binary search each in the sorted lists for the nearest line within the threshold: about 5 screen pixels, so 5 / zoom page units.
4. Apply the smallest correction per axis, then draw guides for every line that now matches exactly. Equal spacing hints ("these three cards are 24 apart") come from comparing gaps between neighbours in the same sorted lists.

That is six binary searches over a few hundred numbers per frame: microseconds. Holding a modifier key to switch snapping off for one drag is a common and welcome escape hatch.

Transforming many layers at once

With several layers selected, the selection box is the union of their world bounds. Moving is easy: the same delta applies to each node's start transform. Resizing is not: dragging the right handle scales the whole selection from its left edge, so each node's position and size are scaled relative to that anchor. Holding Shift keeps the aspect ratio and holding Alt (Option) scales around the center, the usual conventions.

A rotated child inside the selection can't simply get a new width and height without skewing, so the engine either scales the child's own frame or bakes the change into the node's transform. Rotation of a multi selection spins every node around the box center, changing both position and angle. Each of these writes ordinary properties (transform, size), which keeps sync and undo the same for every tool.

Keyboard nudges and shortcuts

Arrow keys move the selection by 1 unit, and Shift with an arrow by 10. A held arrow key repeats keydown about 10 to 30 times a second, depending on the operating system's setting, so treat a run of nudges as one gesture: apply each locally right away, coalesce them into one undo step that closes after about 500 ms without a key press, and send the latest transform to the server at the same steady rate as a drag.

Shortcuts for tools (V for move, R for rectangle, T for text) must not fire while focus is in a panel text field; check e.target before acting, and respect e.isComposing so IME users typing in a field never trigger tools.

Multiplayer: merging edits from many people

Five designers have the file open. Ana moves the hero card, Ben changes its fill to blue, and Chen renames it, all within the same second. The naive sync sends the whole document on save and keeps whatever arrived last.

Ana's save lands last and quietly puts back the old color and the old name: Ben's and Chen's work is gone, and nobody knows. A file lock ("Ana is editing, everyone else is read only") avoids the loss but kills the product: live collaboration is the reason people pick a browser design tool.

We need a way to merge edits made at the same moment. The general background is in the collaboration basics, conflict resolution, operational transformation, and CRDTs lessons. Here we pick the approach that fits a design document, which is a different shape from a text document.

Try the lab: let two users edit the same card. If they change different properties (one the fill, the other the name), both changes survive. Only when both change the same property does one value win, and it is whichever reached the server last, not whoever clicked first. Each user's screen shows their own value until the server's answer arrives, which is the next mechanism.

Applying local edits without flicker

Your own edits must apply at once. But imagine you set the fill to red while Ben's blue is already in flight from the server. The server will order your red after his blue, so red will win. If your client applied Ben's blue when it arrived, your card would flash blue and then back to red when your change came back confirmed.

The rule that prevents the flash: keep a set of unacknowledged (node, property) pairs that you have sent but the server has not yet confirmed. While a pair is in that set, ignore incoming server values for it. Your value is the best guess of the final state, because anything the server sends now was ordered before your change.

const pending = new Map<string, number>(); // "nodeId/prop" -> count of unacked sends

function setLocal(id: NodeId, prop: string, value: unknown) {
  doc.set(id, prop, value);                  // apply now, redraw next frame
  const key = id + "/" + prop;
  pending.set(key, (pending.get(key) ?? 0) + 1);
  socket.send({ t: "set", id, prop, value, seq: nextSeq() });
}

function onServerChange(c: { id: NodeId; prop: string; value: unknown; fromMe: boolean }) {
  const key = c.id + "/" + c.prop;
  if (c.fromMe) {                            // our own change, now ordered: an ack
    const n = (pending.get(key) ?? 1) - 1;
    if (n === 0) pending.delete(key); else pending.set(key, n);
    return;
  }
  if (pending.has(key)) return;              // ours will be ordered later and win
  doc.set(c.id, c.prop, c.value);
}

Creating and deleting nodes

Creating a node must work offline and without waiting, so the client makes the ID. Each session gets a unique session number from the server at connect, and IDs are session:counter, like 42:1093. Two clients can never produce the same ID.

Deleting a node removes it and all its properties from the server, so files don't grow forever with dead data. If you undo your delete, your client still has the deleted node's properties in its undo history and re-creates it with the same ID, so comments and links that pointed at it keep working.

Moving nodes between parents, and ordering siblings

Reparenting is where trees get tricky. Treating a move as "delete here, create there" would give the node a new identity and drop anyone's concurrent recolor of it. Instead, as the scene graph chapter set up, a node's parent link and its position among siblings are one property on the node. A move is one property change, which merges like any other: if Ana moves the card into Frame A while Ben moves it into Frame B, it ends in whichever frame the server saw last, never in both.

One case needs the server's help: a cycle. Ana drags Frame A into Frame B while Ben drags Frame B into Frame A. Each change is valid alone, but together they make A and B each other's parent. The server rejects any parent change that would make a cycle.

For the moment before the rejection arrives, Ana's client may hold both changes; the simple answer is to hide the cycle's nodes until the server's verdict puts them back in a valid place. It's rare, it's brief, and it never corrupts the file.

The order of siblings is the layer stacking order, and two people reorder layers often. Storing an index like 3 breaks the moment someone inserts above it, because every later index must change. Fractional indexing gives each child a position key that sorts as a string; to insert between keys a0 and a1, generate a key that sorts between them, such as a0V.

Only the moved node changes. Two people inserting into the same gap at once can produce the same key. Figma has a separate post on this technique for ordered sequences, and there the server simply gives the second insert a new, unique position; breaking ties by node ID on every client is another option.

Joining, reconnecting, and going offline

The protocol stays simple because joining is simple. On open, the client downloads a snapshot of the file and then exchanges changes over a WebSocket. After a drop, it does the same: download a fresh snapshot, re-apply the edits it made while disconnected on top, and resume.

All the cleverness lives in handling changes on a connected document; reconnection reuses the open path. Figma's post describes exactly this flow, which lets people keep editing through a disconnect.

Presence: cursors, selections, and following

Cursors, selection outlines, and "who is here" avatars are presence: state about people, not the document. It is high frequency and disposable, so it doesn't belong in the document or the undo history. Send each user's cursor position in page coordinates, current selection IDs, and viewport rectangle on a separate channel, throttled to about 10 to 20 updates a second, and have receivers animate between updates so remote cursors glide.

The viewport makes "follow this person" possible: your camera copies theirs. With 200 viewers in a design review, the server should forward cursors only for active editors, or sample them, so 200 people don't each receive 200 cursor streams. The presence and cursors lesson covers the general pattern; here the twist is that positions are in page coordinates, so each receiver maps them through its own camera.

Undo and redo when other people are editing too

In a single-player editor, undo is easy: keep a stack of document snapshots or inverse operations and pop. Put five people in the file and the easy version does damage. If undo walks one shared history, pressing Cmd+Z after Ben recolored the logo undoes Ben's work, not yours.

If undo restores a snapshot from before your last change, it also wipes out everything everyone else did since. Both feel like data loss to the people affected. The rule users expect: undo only reverts my own changes, and leaves everyone else's alone.

The redo rule that keeps documents stable

The subtle part is redo. Single-player redo means "put back the values I had". In a shared file that can overwrite what others did in between. Figma's multiplayer post states a guiding principle that settles it: if you undo several times, copy something, and redo back to the present, the document must end up unchanged.

To get that, undo records the redo step at the moment of undo: it stores the values that were current just before the undo, which may include other people's newer values, not the values from your original edit. Redo symmetrically rewrites the undo step with the values current at redo time.

A worked example. The card's fill starts grey. Ana sets it to red: her undo step stores (fill, before grey, after red). Ben then sets it to blue.

Ana presses undo: her client writes grey and records a redo step with "current before undo: blue". Ana presses redo: her client writes blue, not red. The document is back to exactly what it was before her undo, and Ben's blue survived. With naive redo, Ana's redo would have written red and silently replaced Ben's change.

Edge cases worth naming

• The node was deleted by someone else. Skip that part of the step rather than resurrect a node another person removed on purpose. If nothing in the step still applies, move on to the next step, so a press of Cmd+Z is never silently wasted.
• Someone changed the same property after you. Two reasonable policies: write your old value anyway (predictable: undo means put back what I changed), or skip properties others have touched since. Pick one and apply it everywhere; the first is simpler and is what this guide assumes.
• Gestures are steps. A drag, a resize, a burst of arrow nudges, or a plugin run is one undo step, opened at the start of the gesture and closed at the end, as the editing chapter set up.
• Selection comes back too. Undoing a move should reselect the moved layers, so the user sees what changed. Store the selection with each step, but don't sync it as a document change.
• Memory. Cap the stack, for example at 200 steps, and drop the oldest. Large deletes store whole subtrees, so a byte budget is safer than a count.

Components and instances: one change, many places

A design system file defines a Button once and uses it 3,000 times across 40 screens. When the brand color changes, every one of those buttons must change, except where a designer deliberately changed a label to "Delete account" or swapped the icon. That is the job of components (the master definition, which Figma calls the main component) and instances (live copies that follow the master but keep their own overrides).

Resolving what an instance looks like

Every node inside an instance is identified by a path: the instance's ID plus the ID of the matching node inside the component (and, for nested instances, each instance on the way down). The engine resolves a property by checking the instance's overrides for that path first and falling back to the master. Derived nodes are cached like world transforms and marked dirty when the master or the overrides change.

type OverrideKey = string; // "1:5/fill": path inside the component, then the property

type InstanceNode = SceneNode & {
  type: "INSTANCE";
  componentId: NodeId;
  overrides: Map<OverrideKey, unknown>; // each entry syncs as its own property
};

function resolve(inst: InstanceNode, path: NodeId[], prop: string): unknown {
  const key = path.join(";") + "/" + prop;
  if (inst.overrides.has(key)) return inst.overrides.get(key);
  const master = doc.get(path[path.length - 1]);
  return master ? master[prop as keyof SceneNode] : undefined;
}

Propagating a master change

Keep a reverse index from component ID to its instances. When the master's fill changes, look up the 3,000 instances and mark their derived subtrees dirty. Don't re-derive all of them right away: re-derive the ones on the current page and in view first, so the screen updates in the same frame, and finish the rest in idle time or when their page opens.

Layout can ripple: if the master button gets wider and instances sit in auto layout frames, those frames re-layout too, so the dirty set grows outward. Budget this work per frame (say 4 ms), and keep going in the next frame rather than freezing the editor for a second.

• Override follows identity, not position. Overrides are keyed by the component child's ID, so reordering children in the master keeps each override attached to the right layer.
• A deleted master child leaves its overrides unused. If the master removes the icon, the icon override has nothing to apply to; keep the override stored but unused, so undoing the removal in the master brings the customized icon back intact.
• Reset is delete. "Reset to main component" removes the override entries, and the master's value shows through again.
• Libraries across files. Components published from a team library are versioned. Instances in other files don't change the instant the library changes; the file shows that updates are available, and the designer reviews and accepts them. That turns a cross-file live dependency into an explicit, reviewable step.

Architecture: engine, shell, sync, and workers

We now have every piece. This chapter puts them in boxes and draws the lines between them. The guiding principle is one owner per kind of state: the engine owns the document and everything derived from it; React owns UI state like which panel tab is open; the sync client owns what has and hasn't been confirmed by the server; the server owns the truth.

Why keep the engine on the main thread instead of moving all of it to a worker with OffscreenCanvas? Input events, cursor changes, and the panels live on the main thread. A drag in a worker engine would cost a message hop each way per pointer move, and every hit test for hover would need one too.

Heavy work that doesn't sit on the input path, like decoding a 30 MB snapshot or encoding a PNG export, goes to workers. Rendering in a worker is a valid optimization to mention once the main thread's own budget is under control.

The data flow, end to end: the client fetches file metadata and permissions over HTTPS, then downloads a compressed binary snapshot of the file. A worker decodes it into node records and hands them to the engine, which builds the store, bulk loads the spatial index, and renders the first page.

Images arrive separately, by content hash, from a CDN with long cache lifetimes, and are decoded with createImageBitmap before upload to the GPU. Then the WebSocket opens. From that point, local edits flow from tools to the store to the outbox to the server, and other people's edits flow from the server through the sync client into the store, which marks nodes dirty for the renderer and tells the shell once per frame.

Keeping React fast next to the engine

The properties panel shows the selection's x, y, width, fill, and so on. During a drag those values change 60 times a second. If the engine pushed every change into a React context that the whole app reads, every panel would re-render every frame and steal the drawing budget.

Instead, the engine exposes a small store with a subscribe function and snapshot getters, and each panel subscribes with useSyncExternalStore to just the slice it shows. The engine notifies at most once per frame. The X field re-renders while you drag; the layers panel, whose tree didn't change, does not.

Data model and interface

Most of the data model is already in place from the scene graph chapter. What's left is to say where each kind of data lives on the client, how long it lives, and what goes over the wire. The table is worth sketching in the interview because it shows you separate document state from everything around it.

HTTP endpoints

GET /api/files/f_8Kq2
-> 200 { "id": "f_8Kq2", "name": "Checkout v3", "role": "editor",
         "pages": [{ "id": "0:1", "name": "Flows" }, { "id": "0:2", "name": "Components" }],
         "snapshotUrl": "https://cdn.example.com/s/f_8Kq2/1842.bin",
         "snapshotVersion": 1842, "wsUrl": "wss://mp.example.com/f_8Kq2" }

GET https://cdn.example.com/s/f_8Kq2/1842.bin     (compressed binary, immutable)

POST /api/images            Content-Type: image/png   (raw bytes)
-> 201 { "hash": "9f2c...e1", "width": 2400, "height": 1600 }

GET https://cdn.example.com/img/9f2c...e1        Cache-Control: public, max-age=31536000, immutable

Errors: { "error": { "code": "FORBIDDEN", "message": "You need edit access" } }

Snapshots and images are immutable and named by version or content hash, so the CDN and the browser can cache them forever and never serve a stale copy. A file that changed gets a new snapshot version, not a modified one. Large files can expose a snapshot per page, so the client downloads the page the user opens first and the others on demand (more on that in the performance chapter).

WebSocket messages

// client -> server
type Join = { t: "join"; fileId: string; fromVersion: number; sessionId?: number };
type Changes = { t: "changes"; seq: number; ops: Op[] };       // one batch per frame at most
type Op =
  | { k: "create"; id: NodeId; props: Partial<SceneNode> }
  | { k: "set"; id: NodeId; prop: string; value: unknown }
  | { k: "delete"; id: NodeId };
type Presence = { t: "presence"; cursor?: [number, number]; selection?: NodeId[]; viewport?: Rect };

// server -> client
type Welcome = { t: "welcome"; sessionId: number; version: number; missed: Op[] };
type Ack = { t: "ack"; seq: number; version: number };          // our batch is ordered
type Remote = { t: "remote"; from: number; version: number; ops: Op[] };
type Reject = { t: "reject"; seq: number; reason: "CYCLE" | "FORBIDDEN" | "INVALID"; fix: Op[] };
type PeerPresence = { t: "peer"; session: number; user: UserLite; presence: Presence };

• Batching: changes made in one frame go in one changes message. A drag sends at most one batch every 50 ms with the latest transform; there is no value in sending 60 intermediate positions a second.
• Versions: every ordered batch increments the file version. The simple reconnect path downloads a fresh snapshot; as a refinement for short drops, fromVersion lets the server send only what was missed, or tell the client to reload the snapshot if the gap is too large.
• Rejections carry the fix: a rejected batch includes the server's current values for what it touched, so the client can roll back without a full reload.
• Permissions: the server checks role on every batch. A viewer's client hides editing tools, but the server is what actually enforces it.

Large files: loading, memory, and performance budgets

Everything so far works on a 2,000 layer file. The design system file with 50,000 layers, 20 pages, and 500 images is where designs fall over, and interviewers like to push there. Three things break: opening takes too long, memory runs out, and some edits (a master component change) touch too much at once. Let's put numbers on each.

Load the page you look at, not the whole file

Downloading, decoding, and indexing all 20 pages before the first paint can take 10 seconds or more on a big file. But the user looks at one page. So the snapshot is split per page, and the client loads the open page first, renders it, and fetches others when the user opens them or in idle time. There is one catch: pages depend on each other.

An instance on the Flows page needs its master component, which lives on the Components page. The server therefore also sends the subtrees of every component used by the open page, so instances resolve without loading the rest of that page. Search, "select all with this style", and plugins that walk the whole document need everything; they trigger a load of the remaining pages first, with a progress indicator.

A memory budget, line by line

The images row is the lesson: a 400 KB JPEG on the network becomes 15 MB once decoded. Keep encoded bytes in the HTTP cache, decode with createImageBitmap (which can also downscale while decoding through its resizeWidth and resizeHeight options, supported in current Chrome, Firefox, and Safari), hold decoded bitmaps in a least recently used cache with a byte limit, and call close() on bitmaps you evict so their memory is freed at once.

If the engine is compiled WebAssembly, remember that 32-bit WebAssembly memory tops out at 4 GB, and the browser may kill the tab well before that. The memory leaks lesson covers how to find what's holding memory when this goes wrong.

Spreading big edits across frames

Some edits are inherently big: changing a master used 3,000 times, pasting 5,000 layers, or a plugin renaming every layer. Applying them in one go blocks the main thread for hundreds of milliseconds, and the editor freezes. Apply the document change at once (it's cheap: properties in a map), but schedule the derived work, such as instance re-resolution, layout, index updates, and re-rasterizing tiles, in slices of about 4 ms per frame, visible content first. The screen catches up in a few frames, and the pointer never stops responding.

Performance budgets and how to watch them

Measure in the field, not only on a fast laptop. Time each frame's phases (input, update, render) with performance.now() and report percentiles bucketed by file size and device class.

Use the Long Animation Frames API (PerformanceObserver with type long-animation-frame, available in Chromium browsers) to catch frames that ran long and see which scripts caused them. Track dropped frames during pan and drag as a first class metric, since that is what designers feel. The runtime performance lesson covers the tooling in depth.

Layers panel, properties panel, and accessibility

The panels are where the canvas meets ordinary web UI, and they carry most of the app's accessibility. They have their own scale problem: the layers panel is a tree of up to 50,000 nodes, and the properties panel must show values for one or 300 selected layers.

A layers tree with 50,000 nodes

Rendering one DOM row per node would put 50,000 rows in the panel and make every expand or rename slow. Instead, flatten the tree into the list of visible rows: a node is visible if all its ancestors are expanded. That list is often a few hundred rows even for huge files, and it changes only when something is expanded, collapsed, added, removed, or moved.

Then virtualize it: with fixed 32 px rows, only the 30 to 40 rows in view (plus a few above and below) exist in the DOM, and scroll position maps directly to a row index. The virtualization lesson covers the mechanics; the tree specific parts are below.

• Reveal on select. Clicking a shape on the canvas expands its ancestors in the panel, recomputes the visible rows, and scrolls the row into view.
• Drag to reorder and reparent. Dropping a row between two siblings computes a fractional index between their keys; dropping onto a frame makes it the new parent. Both are the same single property change that multiplayer already handles.
• Tree semantics that survive virtualization. Use role="tree" with role="treeitem" rows carrying aria-level, aria-expanded, and aria-selected. Because most rows aren't in the DOM, also set aria-setsize and aria-posinset so a screen reader can say "item 3 of 12, level 2".
• Keyboard. Up and Down move between rows, Right expands or moves into the first child, Left collapses or moves to the parent, Enter renames, and Space toggles selection, following the WAI-ARIA tree view pattern. Keep one focusable row with a roving tabindex, and keep the focused row rendered even when it scrolls out of view, or focus is lost.

A properties panel for one or many

With one layer selected, the panel shows its values. With many, each field shows the common value or the word "Mixed". Typing into a mixed width field sets every selected layer's width; one undo step, one batch.

Number fields should accept arithmetic (120*2) and allow scrubbing: dragging horizontally on the field's label changes the value, using pointer capture like a canvas drag, with live preview on the canvas and a single commit at the end. Every field is a real labelled input, which makes the panel the most accessible way to make precise edits.

Accessibility of the canvas: be honest

A canvas is a bitmap. Screen readers see one element with no content, and the only built-in way to expose what is drawn is fallback DOM content inside the canvas element, which you must build and keep in sync yourself. A fully accessible visual design tool is an open problem for the whole industry, and claiming otherwise in an interview is a red flag. What a good design can do:

• Make everything keyboard reachable. Every tool, every command in menus and a command palette, and canvas navigation with keys: for example Tab and Shift+Tab to move through sibling layers, Enter to select children, and Shift+Enter to select the parent (the shortcuts Figma uses), plus arrows to nudge.
• Treat the layers panel as the accessible view of the canvas. It is a real tree; selection there and on the canvas are the same state.
• Announce what changes. A polite aria-live region says "Selected Button, frame, 120 by 40" when selection changes from the keyboard, and "Ben joined" for presence, without announcing every remote edit.
• Respect settings. Honor prefers-reduced-motion for animated zoom to fit, keep selection and focus outlines at least 3 to 1 contrast against the canvas, and let users scale the UI.
• Give the canvas a name. role="application" or a labelled region with a short description of the keyboard model, and fallback content explaining how to reach the layers panel.

Plugins, export, and never losing work

Plugins: running strangers' code next to the document

A plugin might rename layers, generate a chart, or check color contrast. It needs to read and change the document, quickly and in large amounts. It must not read the user's session cookies, call our private APIs as the user, draw fake login dialogs over the editor, or freeze the tab. Running plugin code with eval in the page would grant all of that, so it is out.

• Narrow API. The plugin sees a figma-like object with node read and write functions. Every write goes through the same command path as a user edit, so it syncs, respects permissions, and becomes one undo step per plugin run.
• Declared network access. The plugin's manifest lists the domains it may contact, and the host enforces that list (Figma does it with a Content Security Policy and shows the list on the plugin's public page), so users and reviewers can see where data can go.
• Budgets. Interrupt plugin code that runs longer than a few seconds without yielding, and cap its memory, so a bad loop can't freeze the editor.

Export: reuse the renderer, off the main thread

PNG and JPG export must look exactly like the canvas, so they use the same renderer, pointed at an OffscreenCanvas in a worker instead of the screen, at the requested scale. convertToBlob() produces the file. A 4x export of a 3,000 by 2,000 frame is 12,000 by 8,000 pixels, which can exceed the GPU's maximum texture size (8,192 pixels a side on many devices) or a browser's canvas size limit, so large exports are rendered in tiles and stitched.

SVG export is a different path: walk the node subtree and write rect, ellipse, path, and text elements with transforms, gradients, and masks; effects SVG can't express are rasterized into an embedded image. PDF follows the SVG path through a vector PDF writer. Multi-layer exports are zipped in the worker and handed over as a Blob download.

Autosave and short outages

There is no save button. Each change is in the outbox within one frame and on the wire within about 50 ms. The risky moments are the gaps: a dropped connection, a closed laptop, a tab reload. The design covers them in layers:

1. Persist the outbox. Write unacknowledged changes to IndexedDB in small batches. After a crash or reload, the client re-sends them after loading the snapshot.
2. Show honest status. "Saved", "Saving...", or "Offline: changes kept on this device" in the title bar, driven by the outbox length and socket state.
3. Warn before closing with unsent work. A beforeunload handler that only triggers when the outbox is not empty.
4. Reconnect simply. Download a fresh snapshot, re-apply local unsent changes on top, then resume the socket, as the multiplayer chapter described.
5. Keep version history on the server. Periodic checkpoints let a team restore yesterday's file if someone's long offline session overwrote things with last writer wins. The offline-first lesson covers queues and conflict handling in more depth.

Running it in the interview

This question is wide enough that you can spend an hour on any one chapter. The interviewer is watching whether you pick the decisions that matter, put numbers on them, and go deep where they push. A plan for 60 minutes:

Draw the wireframe first, because it gives you and the interviewer shared names for the layers panel, the canvas, and the properties panel. Then draw the architecture with the document store in the middle, and keep pointing at it: every later answer is "this is a property change that goes through the store". That one sentence ties rendering, sync, undo, components, and plugins together, and it is the clearest sign that your design hangs together.

Follow-up questions and strong answers