Design a Document Storage System

Practice a 60-min system design interview answer for Clio on Zoom Whiteboard.

Introduction

30 Second Summary

System design interviews are high-stakes performances. You have 60 minutes to prove you can think like a senior engineer, and without a repeatable framework, most candidates freeze or ramble through an unstructured answer.

In this project, you will practice delivering a complete system design answer for "Design a Document Storage System" on Zoom Whiteboard. You will memorize a 4-phase interview framework, draw a full architecture diagram, and rehearse answers to the deep probing questions that Clio interviewers are known to ask.

What You'll Build

Picture yourself screen-sharing your Zoom Whiteboard in your Clio interview, confidently narrating a complete document storage architecture while your interviewer nods along and digs into your trade-off reasoning.

By the end of this project, you'll have:

A repeatable 4-phase framework you can apply to any 60-minute system design prompt without freezing or losing track of time.
A complete architecture diagram with labeled data flows for a document storage system that you can narrate end-to-end in under 15 minutes.
A confident explanation of how concurrent edits resolve without data loss, including the trade-offs between OT and CRDTs that interviewers love to probe.
Rehearsed responses to Clio-style stress-test questions about scaling, multi-tenancy, and security that you can deliver in under 60 seconds each.
Secret Mission: Handle a mid-interview curveball by adapting your design to support offline editing.

Are there any prerequisites?

You should have a basic understanding of client-server architecture, databases, and APIs. You do not need prior system design interview experience.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters to you.

Prepare Your Zoom Whiteboard Workspace

Walking into a system design interview with an empty whiteboard and no structure is the number one reason candidates freeze and lose time. You spend precious minutes deciding where to write instead of deciding what to write.

In this step, you will build a pre-structured workspace on Zoom Whiteboard that gives you a visible scaffold to follow under pressure. Think of it as laying out your interview answer's skeleton before the clock starts.

In this step, get ready to:

Create a new Zoom Whiteboard divided into 5 labeled time zones.
Pre-write memory anchors in the Requirements and Estimation zones.
Save your board as a reusable template and practice navigating it.

Create your whiteboard zones

The 4-phase framework splits a 60-minute system design interview into timed sections. Each zone on your whiteboard maps to one phase, so you always know what to cover and how much time you have left.

What is the 4-phase framework?

It breaks any system design interview into four moves: clarify requirements, estimate capacity, draw the high-level architecture, and deep-dive into the hardest components. Most top-tier companies calibrate on this structure internally.

The time splits are not equal. Architecture and Deep Dive get the lion's share because that is where you demonstrate depth.

In Zoom, click Whiteboards in the left sidebar.
Click New Whiteboard to create a blank board.
Select the Line or Shape tool from the toolbar at the bottom of the canvas.
Draw dividing lines to split your canvas into 5 distinct zones, arranged left to right or in a grid layout that feels natural to you.
Select the Text tool and label each zone with these exact titles and time ranges:

Requirements (0:00-0:08)
Estimation (0:08-0:12)
Architecture (0:12-0:35)
Deep Dive (0:35-0:55)
Wrap-up (0:55-1:00)

You should now see five clearly separated zones on your canvas, each with a visible label and time allocation.

Make Architecture the largest zone

Architecture gets 23 minutes of the interview. Give it the most physical space on your whiteboard so you have room to draw boxes and arrows without cramping.

Can't find the shape or line tool?

The toolbar in Zoom Whiteboard sits at the bottom of the screen. If you do not see it, hover your mouse near the bottom edge of the canvas. The shape tool looks like a square icon, and the line tool looks like a diagonal line.

Help me find the drawing tools in Zoom Whiteboard.

Pre-write your memory anchors

Under pressure, your brain blanks on what to cover first. Pre-written prompts act as memory anchors that keep you moving forward even when nerves hit.

Click into your Requirements zone.
Using the Text tool, write two column headers side by side: Functional on the left and Non-Functional on the right.
Click into your Estimation zone.
Write three prompts stacked vertically: DAU: on the first line, Peak QPS: on the second line, and Storage: on the third line.

Your Requirements zone now has two clear columns waiting to be filled, and your Estimation zone has three prompts that tell you exactly what numbers to calculate.

Why these specific prompts?

DAU (Daily Active Users) sets the scale. Peak QPS (Queries Per Second) determines how beefy your servers need to be. Storage tells you how much data you are managing over time. Together, these three numbers size the system to real load instead of designing in a vacuum.

Interviewers expect you to state assumptions out loud and do quick math. Having these prompts visible means you never forget to do it.

Save your template and practice navigating

Your interviewer will see this board via screen share. If you fumble with panning and zooming during the interview, it signals discomfort with your own tools. Practicing now eliminates that friction.

Give your board a clear name by clicking on the title area at the top and typing System Design Template.
Zoom Whiteboard auto-saves, so your board is already persisted. Before your real interview, you can duplicate this board from your Whiteboards list so you always have a clean copy.
Practice panning between zones. Click and drag on empty canvas space to move around, or use two-finger scroll on a trackpad.
Practice zooming. Pinch on a trackpad, or use Cmd +/- (macOS) or Ctrl +/- (Windows) to zoom in and out.
Pan from the Requirements zone all the way to the Wrap-up zone and back. Confirm that every label and time range is readable at the zoom level you will use during screen share.

Before you move on, predict: can you pan from Requirements to Deep Dive in under 3 seconds without losing your place?

Try it now. You should be able to land on any zone within a couple of seconds and read its label clearly. If any zone feels cramped or the text is too small at your default zoom level, resize your zones or increase font size before continuing.

Zones feel cramped or hard to read?

If your five zones do not fit comfortably on one screen, that is fine. The board is meant to be panned, not seen all at once. What matters is that each individual zone has enough room for you to write content inside it without overlapping the neighbouring zone.

Try making the Architecture zone at least twice the width of the Estimation zone. It will hold the most content during the interview.

Help me arrange my whiteboard zones so they are easy to navigate.

Your interview workspace is ready. Next up, you will fill in the Requirements and Estimation zones by scoping the actual problem: designing a document storage system.

Scope the Problem - Requirements and Estimation

Your workspace is set up with clear zones and timing labels. Now comes the move that separates strong candidates from ones who freeze: defining what you are actually building before touching the architecture.

Jumping straight to drawing boxes is the biggest red flag for interviewers. Clio reviewers specifically want you to explain every choice you make and go into a lot of depth. You cannot justify design choices without first establishing what you are optimizing for.

In this step, get ready to:

Ask clarifying questions that would change the design.
Write functional and non-functional requirements.
Fill in capacity estimation numbers.

Ask clarifying questions out loud

In a real interview, the prompt is intentionally vague. The interviewer expects you to ask questions that reveal hidden constraints before you start designing.

Why do clarifying questions matter so much?

A document system with 5 concurrent editors is fundamentally different from one with 500. A system that needs real-time collaboration requires WebSocket connections and conflict resolution, while save-and-refresh can use simple REST APIs.

Each clarifying question narrows the design space. Your interviewer sees that you understand the question is ambiguous and that you can identify which constraints actually shape the architecture.

Imagine the interviewer says: "Design a document storage system like Google Docs."

Practice asking these 4 clarifying questions OUT LOUD, as if the interviewer is sitting across from you:

"How many concurrent editors per document?"
"Do we need real-time collaboration or is save-and-refresh acceptable?"
"What's the document size range?"
"Any compliance requirements like data residency?"

Write your assumed answers next to each question in the Requirements zone. For example: "Up to 50 concurrent editors," "Real-time required," "1KB to 10MB per document," "Data residency for regulated industries."

You should now see your assumed answers written beside each question in the Requirements zone. These assumptions drive every decision you make from here.

Say it before you write it

In the actual interview, always verbalize your assumption before writing it down. This gives the interviewer a chance to redirect you ("Actually, assume no compliance requirements for now") and shows collaborative thinking.

Write your functional and non-functional requirements

Your clarifying questions established the constraints. Now you translate those into concrete requirements that your architecture must satisfy.

In the Functional column of your Requirements zone, write these 5 items:

(1) Create, read, update, delete documents.
(2) Real-time collaborative editing with multiple users.
(3) Version history and restore.
(4) Sharing with permission levels (view/edit).
(5) Live cursor and presence indicators.

In the Non-Functional column, write these 4 constraints:

Edit propagation latency under 200ms.
99.9% availability.
Strong durability with no edit ever lost.
Support up to 50 concurrent editors per document.

Your Requirements zone should now have two filled columns. The functional list describes what the system does. The non-functional list describes how well it must do it.

Why these specific non-functional requirements?

Each constraint forces a design decision. The 200ms latency budget means you cannot poll a server for updates. You need push-based communication like WebSockets.

"No edit ever lost" means you need an append-only log, not just overwriting the latest state. These constraints will drive every box you draw in the next step.

Fill in your capacity estimation

Capacity estimation shows the interviewer you size a system to its actual load, not in a vacuum. You do not need exact math. The goal is demonstrating that you think about scale.

In your Estimation zone, fill in the DAU prompt with: 10M.
Fill in the Peak QPS prompt with: 3M operations/second.
Fill in the Storage prompt with: 100TB (1B documents at 100KB average).

Now practice narrating the math out loud, as you would in the interview:

"10 million DAU. Average 3 edits per second per active document. 1 million concurrently active documents gives us 3 million operations per second at peak write throughput. Average document size is 100KB. With 1 billion total documents, that's 100TB of storage."

What does this estimation signal to the interviewer?

The interviewer does not care if your math is off by 2x. They care that you stated your assumptions out loud (10M DAU, 3 edits/sec, 1M active docs) and derived a throughput number from them.

3M ops/sec tells you this is not a single-database problem. 100TB tells you object storage is required. These numbers directly shape your architecture in the next step.

Before you move on, take a moment to look at your whiteboard. Do you think an interviewer seeing your Requirements and Estimation zones would have enough context to understand what system you are about to design?

Pan across your whiteboard and confirm: your Functional column has 5 numbered items, your Non-Functional column has 4 constraints with specific numbers, and your Estimation zone has all three prompts filled with values and brief derivation logic visible.

Feeling like the estimation is too hand-wavy?

That is normal. The estimation phase should take 3-4 minutes maximum in the real interview. If you spent more than 5 minutes on the numbers, you over-invested. The signal is "I think about scale" not "I can do long division."

If your numbers differ from the ones above, that is fine as long as you stated your assumptions clearly and derived your throughput from them.

help me understand what level of detail is expected in the capacity estimation phase of a system design interview

You have a scoped problem with concrete constraints and scale targets. Next, you will translate these requirements into boxes and arrows. Your first architecture will satisfy the basic read and write paths, but it will have a critical gap: it cannot handle what happens when two people edit the same paragraph at the same time.

Draw Your First Architecture

Your requirements are locked in and your capacity numbers are on the board. You now know what the system needs to do and roughly how much load it faces.

Now it is time to draw the boxes. A strong interview answer builds incrementally. You start with the simplest architecture that satisfies the functional requirements, then layer on complexity only where the design falls short. This approach shows the interviewer you think in trade-offs, not in over-engineered moonshots.

In this step, get ready to:

Draw a 5-7 box diagram covering the core read/write path for documents.
Add a real-time communication layer for broadcasting edits to connected clients.
Narrate both the write path and the read path end-to-end in under 2 minutes.

Draw the core read/write architecture

Every document storage system has two fundamental paths: writing (creating or editing a document) and reading (opening one). Your first diagram captures both paths with the minimum set of components needed to serve them.

In your Architecture zone, draw a box labeled Client (Web/Mobile) on the far left.
Draw an arrow from Client to a Load Balancer box.
Draw an arrow from the Load Balancer to an API Gateway box.
Draw an arrow from the API Gateway to a Document Service box.
From the Document Service, draw two arrows going right. One arrow points to a PostgreSQL box labeled "metadata: ownership, permissions, timestamps". The other arrow points to an S3 / Object Storage box labeled "document content, snapshots".
Draw a Redis Cache box between the Document Service and PostgreSQL. Add arrows in both directions to show cache reads and writes for frequently accessed documents.
Narrate each box out loud as you draw it. Say what it does and why it exists. For example: "The Load Balancer distributes requests across multiple API Gateway instances so no single server is overwhelmed."

Your Architecture zone should now have 6 boxes connected by arrows flowing left to right.

Why separate metadata from content?

Document metadata (who owns it, who can access it, when it was last edited) is small, structured, and queried constantly. PostgreSQL handles this well with indexes and relational queries.

Document content (the actual text, potentially hundreds of kilobytes) is large and mostly read as a whole blob. Object storage like S3 is cheaper and scales better for this access pattern.

Add the real-time communication layer

Your current diagram handles a single user reading or saving a document. But the requirements say multiple users collaborate in real time. That needs a persistent connection between client and server, not request-response HTTP.

Draw a WebSocket Gateway box. Add an arrow from the Client box to this new gateway, separate from the REST API path.
Draw a Collaboration Service box connected to the WebSocket Gateway. This service handles incoming edit operations.
Draw an Operation Log box connected to the Collaboration Service. Label it "append-only". This is where every edit is persisted before being broadcast.
Draw a Message Broker box (label it "Redis Pub/Sub or Kafka"). Connect it from the Collaboration Service, and draw an arrow from the broker back to the WebSocket Gateway.
Label the path from the Collaboration Service through the broker to the WebSocket Gateway as "Edit broadcast." This label tells the interviewer exactly what this path does at a glance.
Say this narration out loud: "When a user makes an edit, it flows through the WebSocket Gateway to the Collaboration Service, gets persisted in the Operation Log, then published via the message broker to all other connected clients through the WebSocket Gateway."

Your diagram now has 5-7 major boxes covering both REST and real-time paths.

Why WebSockets instead of polling?

HTTP polling would mean each client asks "any new edits?" every few hundred milliseconds. With 50 concurrent editors, that is 50 requests per document per interval, most returning nothing.

A WebSocket connection stays open. The server pushes edits the instant they are persisted. After the initial handshake, each frame has only 2-14 bytes of overhead versus full HTTP headers on every poll request.

Trace both paths end-to-end

A diagram full of boxes means nothing if you cannot narrate the data flow. Interviewers evaluate whether the system actually works as a connected whole, not just whether you drew the right components.

Trace the write path out loud: "Client sends an edit via the WebSocket Gateway to the Collaboration Service. The Collaboration Service persists the operation to the append-only Operation Log, then publishes it to the Message Broker. The broker fans it out to the WebSocket Gateway, which pushes the edit to all other connected clients."
Trace the read path out loud: "Client requests a document via the API Gateway. The Document Service fetches the latest snapshot from S3 and applies any operations since that snapshot from the Operation Log. It returns the fully rendered document to the client."
Check your whiteboard. If you cannot follow either path by tracing arrows from left to right without ambiguity, adjust your arrows or reposition boxes until the flow reads clearly.
Time yourself narrating both paths. Your target is under 2 minutes total. If you run long, tighten your narration to one sentence per box.

Why narrate out loud?

In the real interview, you are narrating while drawing. The interviewer cannot read your mind. Practicing the narration now means you will not freeze when explaining your diagram under time pressure.

Keep each box to one sentence of explanation. If you need more than one sentence per box, your architecture may be too complex for this phase.

Now ask yourself this: what happens if User A and User B both edit the same paragraph at the same time? Look at your write path. Both edits arrive at the Collaboration Service and both get appended to the Operation Log. But which edit wins? Does one overwrite the other?

Your current architecture has no mechanism to resolve this conflict. If two users type in the same spot simultaneously, one user's edit silently disappears or the document corrupts. That is the gap.

This gap is intentional

In a real interview, drawing the simple version first and then naming its limitation demonstrates mature engineering thinking. You do not over-engineer upfront. You identify the problem and solve it incrementally. That is exactly what the next step does.

Your architecture handles the basic read and write paths cleanly. But you have identified a critical flaw: concurrent edits have no conflict resolution. Next up, you will design the mechanism that ensures two simultaneous edits never corrupt the document.

Solve the Hard Problem - Concurrent Editing

Your architecture diagram has clear read and write paths traced end-to-end. But it has a critical flaw that any Clio interviewer will probe.

If two users edit the same sentence at the same time, one edit overwrites the other, or the document corrupts. Designing the conflict resolution layer is what separates a passing answer from one that demonstrates real depth.

In this step, get ready to:

Diagram the conflict scenario that breaks your current design.
Compare OT and CRDT approaches and justify your choice.
Draw the complete resolution flow showing how concurrent edits converge without data loss.

Diagram the conflict scenario

Before you can solve concurrent editing, you need to show the interviewer you understand exactly why a naive approach fails. Drawing the problem makes your solution feel earned rather than memorized.

Navigate to your Deep Dive zone on your Zoom Whiteboard.
Draw two stick figures or labeled boxes side by side: "User A" on the left and "User B" on the right.
Under User A, write: "Inserts 'Hello' at position 5."
Under User B, write: "Deletes character at position 3."
Draw arrows from both users pointing down to a single document box.
Write next to the document box: "Both operations sent to server at the same time."

Now annotate why this breaks. Write below the diagram: "Without conflict resolution, applying both operations at their stated positions produces a corrupted document because positions shift after each operation."

Why does last-write-wins fail here?

User B deletes at position 3, which shifts everything after it left by one. User A's insert was calculated for position 5 in the original document. After B's delete, position 5 now refers to a different character.

If the server blindly applies both at their original positions, the resulting document is neither what A intended nor what B intended. This is the core problem your design must solve.

Practice saying this scenario out loud in under 30 seconds, pointing at your diagram as you explain each part.

Show the problem before the solution

Drawing the failure case first demonstrates to the interviewer that you build incrementally. You are not just reciting a memorized answer. You are reasoning from the gap in your architecture toward its resolution.

Compare OT vs CRDT and choose your approach

There are two established approaches to conflict resolution in collaborative editors. You need to choose one and justify it clearly. Interviewers want to hear that you evaluated alternatives, not that you jumped to the first option.

Below your conflict scenario diagram, draw a two-column comparison using the text tool or a dividing line.
Label the left column "OT (Operational Transformation)" and the right column "CRDT (Conflict-free Replicated Data Types)."

In the OT column, write these key points: "Server orders all operations. Transforms concurrent ops so positions stay correct. Proven at Google Docs scale. Lower memory overhead."
In the CRDT column, write: "Each character carries unique ID metadata. No central server needed. Works offline and peer-to-peer. Higher memory overhead per character."

Below the comparison, write your choice: "Choose OT with server ordering."
Write your justification: "We already have a centralized server. OT is simpler with a single source of truth, proven at Google Docs scale, and has lower memory overhead than CRDTs which require per-character metadata."
Write the trade-off acknowledgment: "If we needed offline-first editing or peer-to-peer sync, we would choose CRDTs instead."

Why does this trade-off matter to Clio interviewers?

Clio reviewers specifically say they want you to "explain every choice you make" and "go into a lot of depth." Stating your choice without the trade-off sounds like memorization. Stating the trade-off shows you understand when your choice would be wrong.

OT powers Google Docs, Figma, and most production collaboration software in 2026. For a centralized SaaS product like Clio's, OT is the pragmatic choice.

Practice delivering this comparison out loud. Point at each column as you explain it, then state your choice and why. Target under 60 seconds.

Draw the OT resolution flow

The comparison shows the interviewer you evaluated options. Now you need to prove you understand how OT actually works by drawing the resolution flow step by step.

Below your OT vs CRDT comparison, draw a numbered sequence diagram with 5 steps. Use arrows between Client A, Server, and Client B.
Step 1: Draw an arrow from Client A to Server. Label it: "Client A sends insert operation to server."
Step 2: At the Server box, write: "Server assigns sequence number and appends to Operation Log."
Step 3: Draw an arrow from Client B to Server. Label it: "Client B's concurrent delete arrives. Server transforms it against already-applied operations so positions are adjusted correctly."
Step 4: Draw arrows from Server to both Client A and Client B. Label: "Server broadcasts transformed operations to all connected clients."
Step 5: Write at the bottom: "All clients converge to the same document state."

Now annotate the Operation Log to show the interviewer you have thought about persistence.

Next to your Server box (or near the Operation Log reference from your Architecture zone), write: "Append-only, event-sourced."
Add: "Periodic snapshots every 1000 ops for fast cold-start document loads."
Add: "Full version history reconstructed from the log."

What does event-sourced mean here?

Instead of overwriting the document with each edit, the system stores every individual operation as an event. The current document state is rebuilt by replaying all operations since the last snapshot. This gives you version history for free and guarantees no edit is ever lost.

The snapshot every 1000 ops prevents the replay from becoming expensive when loading a document that has not been opened in a long time.

Pan back to see your entire Deep Dive zone. Confirm you can see the conflict scenario diagram, the OT vs CRDT comparison, and the 5-step resolution flow all at once without scrolling.

Deep Dive zone feeling cramped?

If your three diagrams overlap or feel unreadable, use Zoom Whiteboard's zoom out feature to see more of the canvas. You can also drag elements to spread them vertically. Your interviewer will see whatever zoom level you share, so readability at a distance matters.

Help me organize my Deep Dive zone so it reads clearly during screen share.

Before you rehearse, think about this: if you had to explain your entire Deep Dive zone from the conflict scenario through to the resolution flow, how long do you think it would take you?

Set a timer on your phone and narrate your entire Deep Dive zone out loud. Start at the conflict scenario, move through your OT vs CRDT choice, and finish with the resolution flow. Point at each diagram as you speak.
Check your timer. Your target is under 3 minutes for the full explanation.

What should I see?

Your Deep Dive zone should contain three distinct sections, readable at screen-share zoom level. A conflict scenario showing two concurrent edits and why naive application fails. A two-column OT vs CRDT comparison with your justified choice. A 5-step resolution flow with the Operation Log annotated as append-only, event-sourced, with snapshots every 1000 ops.

Taking longer than 3 minutes?

If your narration runs long, you are likely over-explaining the conflict scenario. Spend 30 seconds on the problem, 30 seconds on the trade-off, and the remaining time on the resolution flow. The flow is where the depth is. Practice trimming your problem statement to two sentences.

Help me tighten my OT explanation to fit under 3 minutes.

Your Deep Dive zone now proves you can go beyond surface-level boxes and arrows. Next, you will stress-test your entire design against the exact follow-up questions Clio interviewers are known to ask.

Stress-Test Under Clio-Style Probing

Your architecture now handles the hardest distributed systems problem in document collaboration: concurrent editing without data loss. But drawing boxes and arrows is only half the battle in a Clio system design round.

Clio interviewers are known for probing every choice with follow-up questions about what breaks at scale. Having prepared answers to common follow-ups is the difference between freezing and demonstrating confident, senior-level reasoning under pressure.

In this step, get ready to:

Write and answer three scaling stress-test questions in your Wrap-up zone.
Write and answer two Clio-specific security and multi-tenancy questions.
Practice delivering a 90-second wrap-up summary out loud.

Write and answer scaling questions

Interviewers push on scaling because it reveals whether you understand the limits of your design. Each question targets a different stress point in your architecture.

Navigate to your Wrap-up zone on your Zoom Whiteboard.
Write Q1 and its answer: "What if one document goes viral with 500 editors?" Answer: Per-document server affinity via consistent hashing on document ID. Cap concurrent editors at 100 with a waitlist. Serve read-only viewers from replicas.
Write Q2 and its answer: "What happens if the WebSocket server crashes?" Answer: The operation log is the source of truth. A new server replays from the last snapshot plus subsequent ops. Clients reconnect with exponential backoff and re-sync via their state vector.
Write Q3 and its answer: "How do you handle a document not opened in months?" Answer: Cold storage tier with latest snapshot in S3. Load on-demand into hot cache when requested. Evict from Redis after inactivity timeout.

Why these three questions?

Each question tests a different failure mode. Q1 tests horizontal scaling under load. Q2 tests fault tolerance and recovery. Q3 tests cost optimization through tiered storage.

Together they show you think about your system from multiple angles, not just the happy path.

Practice answering Q1 out loud. Time yourself. Target under 60 seconds per answer.
If your answer runs over 60 seconds, cut the explanation to just the core mechanism and one supporting detail.

You should see three questions with concise answers visible in your Wrap-up zone. Each answer names the mechanism first, then one concrete detail.

Answers running too long?

The most common mistake is over-explaining. Each answer should be 2-3 sentences at most. Lead with the mechanism ("consistent hashing on document ID"), then one supporting detail ("cap at 100 with a waitlist").

If you find yourself saying "and also" more than once, you are going too deep for a stress-test answer. Save depth for when the interviewer follows up.

Help me tighten my stress-test answers to under 60 seconds each.

Write and answer Clio-specific security questions

Clio builds legal technology for law firms. Data isolation and compliance are not just nice-to-haves. They are core product requirements that interviewers expect you to address unprompted.

Write Q4 and its answer: "How do you ensure Law Firm A never sees Law Firm B's documents?" Answer: Tenant-scoped access at every layer. Database sharding by tenant ID (Clio shards their MySQL this way). Row-level security policies. ACL check on every API call before any data access. Tenant ID in every query predicate.
Write Q5 and its answer: "What about GDPR right to deletion?" Answer: Soft-delete with scheduled hard purge of all related records. Operation log entries for that document are also purged. Tenant data isolation means deletion is scoped to one firm without affecting others.

Why mention Clio's actual sharding approach?

Clio uses MySQL sharded by tenant. Mentioning this shows you researched the company's architecture and can map your design to their real constraints.

You do not need to guess their exact stack. Saying "a company like Clio would naturally shard by tenant because law firm data never crosses firm boundaries" demonstrates the same signal.

Practice answering Q4 and Q5 out loud. Keep each under 60 seconds.
Check that your Wrap-up zone now shows all five questions with answers clearly readable.

Your Wrap-up zone should now have five questions visible. At least two (Q4 and Q5) address data isolation or security.

Signal depth without being asked

Clio reviewers say they want candidates to "go into a lot of depth" and "explain every choice." Bringing up multi-tenancy before the interviewer asks demonstrates you understand their domain. It is one of the strongest signals you can send in a legal-tech system design round.

Practice your 90-second wrap-up summary

The last 5 minutes of a system design interview are your chance to leave a strong final impression. A crisp summary shows you can communicate at the executive level, not just the implementation level.

Write this summary structure in your Wrap-up zone as bullet points you can glance at while speaking:
Opening line: "We designed a document storage system supporting real-time collaboration via server-ordered OT."
Core components: "An append-only operation log for durability and version history. WebSocket-based edit broadcasting. Tenant-isolated data access."
Key trade-offs: "We chose OT over CRDTs for simplicity given our centralized architecture. We chose eventual consistency for the read path to optimize latency."
Future work: "Given more time, I would explore geo-distributed deployment for global latency reduction, smarter cache invalidation strategies, and more granular block-level permissions."

Why end with future work?

Naming what you would do with more time shows the interviewer you see beyond the 60-minute boundary. It demonstrates you understand your design has limits and you know exactly where to invest next.

Keep it to exactly three items. More than three sounds like you are listing things you forgot to cover.

Before you time yourself, how long do you think this summary will take to deliver out loud? Make a guess.

Set a timer on your phone.
Deliver the entire summary out loud, speaking at a natural conversational pace.
Stop the timer when you finish.

Your target is 90 seconds or under. Most people overshoot on the first attempt because they add qualifiers and hedging language. If you are over 90 seconds, cut one sentence from each section and try again.

Summary keeps running over 2 minutes?

Remove any sentence that starts with "basically" or "so essentially." These are verbal filler that adds time without adding signal.

Treat the summary like an elevator pitch. Name the system, the core mechanism, one trade-off, and three future items. Nothing else.

Help me cut my wrap-up summary to 90 seconds.

Run through the summary one more time at 90 seconds or under to confirm you can hit the mark consistently.

You now have all five zones of your whiteboard filled. Your Wrap-up zone contains five stress-test answers you can deliver in under 60 seconds each, plus a wrap-up summary you can deliver in 90 seconds.

Your interview template is complete. You have a full architecture with prepared responses to the exact probing questions Clio interviewers are known to ask. Next up, you will tackle the curveball that separates good answers from great ones.

Secret mission

Handle the Curveball - Now Add Offline Support

Clio interviewers are known for introducing new constraints mid-interview to test adaptability. In this mission, you'll handle the dreaded curveball: "What if the user needs to edit documents while on a plane?" This fundamentally challenges your OT choice, because OT relies on a central server to order operations.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on Zoom Whiteboard, so there are no ongoing costs.

Resources you used:

Zoom Whiteboard board (your interview template with all five zones, architecture diagram, and annotations).

Keep everything running

No action needed. Choose this if you are still actively rehearsing for your Clio interview or want to refine your diagrams further.

Your Zoom Whiteboard stays in your account and is free to keep indefinitely.
You can duplicate the board before your real interview to start fresh while preserving your practice version.

Pause - I'll come back to this later

Nothing to shut down. Your Zoom Whiteboard does not consume any active resources while idle.

Your board remains saved in your Zoom account automatically.
When you are ready to practice again, open Zoom and navigate to your saved whiteboards.

Delete - I don't want to use this again

Remove your practice whiteboard entirely if you no longer need it.

Open Zoom and click on the Whiteboards tab in the left sidebar.
Find your interview template board in the list.
Click the three-dot menu (...) next to the board name.
Select Move to Trash to delete the board.

That's a Wrap!

Nice work! You've just completed a full system design interview rehearsal for a document storage system, the exact type of question Clio asks in their 60-minute design round.

You've learned how to:

Walk through a 4-phase system design framework with proper time allocation, so you never freeze or lose track of where you are in a 60-minute round.
Design a complete document storage architecture with real-time collaboration on Zoom Whiteboard, including WebSocket-based edit broadcasting and server-ordered OT for conflict resolution.
Explain the OT vs CRDT trade-off and deliver confident answers to Clio-style probing questions about scaling, multi-tenancy, and security.
Secret Mission: Demonstrated adaptability by evolving your design to handle offline editing, the most common curveball for this problem type.

Ready to quiz yourself?