What is the best way to practice mock system design interviews?

The best way to practice mock system design interviews is to use a structured platform like System Design Lab. It provides real interview questions (design URL shortener, design Twitter, design Netflix), an interactive diagram builder, an AI interviewer that asks follow-up questions, and detailed feedback on your architecture, scalability decisions, and trade-offs — exactly like a real FAANG interview.

How do I prepare for a system design interview?

To prepare for a system design interview: (1) Learn core concepts like distributed systems, caching, databases, sharding, and message queues. (2) Practice drawing architecture diagrams under time pressure. (3) Take knowledge quizzes to test your understanding. (4) Do mock system design interviews with AI feedback to get comfortable explaining your decisions. (5) Review community solutions to see how others approach the same problems. System Design Lab covers all five steps in one platform.

What system design interview questions should I practice?

Common system design interview questions include: Design a URL shortener, Design Twitter/social media feed, Design Netflix/video streaming, Design a distributed cache, Design a rate limiter, Design a notification system, Design a ride-sharing app like Uber. System Design Lab offers a growing bank of real interview problems — Twitter, YouTube, URL shortener, Uber and more — covering the major categories asked at FAANG and top-tier tech companies.

Is there a free mock system design interview tool?

Yes — System Design Lab offers a free 7-day trial with access to 3 mock system design interview problems, all learning modules, all quizzes, and community solutions. No credit card required. Premium (₹999 for 90 days) unlocks unlimited problems and AI interviewer access.

How does System Design Lab's AI interview feedback work?

After you submit your system design, the AI evaluates your written explanation and architecture diagram together. It scores you on completeness, scalability, fault tolerance, and clarity, then gives you specific, actionable feedback — similar to what a senior engineer would say after your interview. You can also chat with an AI interviewer in real-time during your attempt.

System Design Lab›System Design Questions›Design Slack

Design Slack

MediumMessaging Systemsmessagingreal-timewebsocketssearchnotifications

Question Overview

Design a real-time team chat platform with workspaces, channels, direct messages, and threads. The core problems are holding millions of WebSocket connections, fanning messages out to channel members in a consistent order, and tracking unread counts and presence at scale.…

Requirements

Workspaces with public and private channels, DMs, group DMs, and threaded replies
Send, edit, and delete messages with mentions and reactions, delivered in real time to online members
Channel history with infinite scroll, plus per-channel unread counts and mention badges synced across devices
Presence and typing indicators, and push notifications for offline and mobile users
Search across every channel a user can access, with new messages indexed within seconds
Under 500 ms p99 delivery, durable acknowledged messages, and one consistent order per channel

Back-of-the-envelope numbers

Messages: 1B/day ÷ 86,400 s ≈ 11.6K messages/s average, ~35K/s at 3× peak during working hours
Fan-out: 11.6K/s × 20 online members ≈ 232K deliveries/s average, ~700K/s at peak; one post to a 100K-member channel is 100K pushes alone
Connections: 10M concurrent WebSockets ÷ 50K per gateway server = 200 servers, ~300 with headroom for failover
Storage: 1B × 500 B = 500 GB/day ≈ 183 TB/year of message data, ~550 TB/year with 3× replication
Presence: 10M online users heartbeating every 30 s ≈ 333K updates/s, so presence lives in memory, not in the message store
Unread pointers: 20M users × ~50 channels = 1B last-read entries × ~24 B ≈ 24 GB in a sharded key-value store

Key components

Gateway servers: hold WebSocket connections, authenticate on connect, and track which channels each connection subscribes to
Message service: checks membership, assigns a per-channel sequence number, and persists the message before acknowledging the sender
Message store: wide-column or sharded SQL, partitioned by channel_id and time bucket and clustered by sequence for fast history range reads
Channel fan-out: a router maps each channel to the gateways holding its subscribers, so a 100K-member post fans out to hundreds of gateways, not 100K users
Unread tracking: per user per channel last_read_seq; the unread count is latest_seq minus last_read_seq, with mentions counted separately
Presence service: in-memory heartbeats with TTLs, publishing changes only to clients currently displaying that user
Search and notifications: messages stream through Kafka to a per-workspace search index with ACL filtering, and to APNs or FCM for offline users

Common mistakes

Ordering messages by each server's receive timestamp, so clock skew shows members different orders instead of one per-channel sequence
Writing every channel message into each member's inbox, turning one post in a 100K-member channel into 100K writes
Computing unread counts with COUNT(*) over messages on every load instead of subtracting sequence numbers
Broadcasting every presence change to every member of a 200K-member workspace, which grows quadratically with workspace size
Acknowledging the sender before the message is durably stored, so a crash loses messages users believe were sent
Assuming WebSockets never drop; without resuming from the last seen sequence, reconnecting clients silently miss messages

Likely follow-ups

How would a client that was offline for three days efficiently catch up across 200 channels?
How would you support a channel shared between two different companies' workspaces?
How would you propagate edits and deletes so search results and every client stay consistent?
How would you deploy a new gateway version without dropping 10M connections at once?
How would you enforce per-workspace retention policies and legal holds?
How would you keep unread state consistent across a user's desktop and mobile clients?

No community solutions yet

Be the first to publish your solution

Practice ‘Design Slack’ with an AI Interviewer

Get scored feedback on your diagram, scalability approach, and trade-offs. Free while we grow — up to 3 full interviews a day.

Try a 5-minute drill — no signup