Quiz

Slack mobile design quiz

Check the Slack mobile design post: product behavior, sync, push, local state, and scaling tradeoffs.

Questions

12

Est. time

~9 min

Read the post View the series

Score

01
Mobile startup sync

When the Slack mobile app opens after being offline overnight, what should it do first?
Options for question 1
1. A. Block the UI until every workspace, channel, thread, reaction, and unread counter has fully synced.
2. B. Show cached state first, then sync the current workspace and conversation.
3. C. Clear the local cache to avoid showing stale data.
4. D. Only rely on push notifications because they can describe every missing event.
Correct answer: B.

The mobile app should feel useful quickly. It can show cached workspaces, recent conversations, unread counts, and pending messages immediately, then sync high-priority state before older history. A full workspace sync on startup would make the app feel slow and fragile.
02
Offline send and idempotency

Why should a mobile client attach a client-generated idempotency key when sending a message?
Options for question 2
1. A. It lets the server dedupe retries after a committed send times out.
2. B. It lets the phone rebuild message history later, so durable server storage can be skipped.
3. C. It guarantees the push notification will arrive before the WebSocket event.
4. D. It removes the need for local pending message state.
Correct answer: A.

Mobile networks fail in awkward ways. The server might commit the message while the client times out. An idempotency key lets the client retry safely without creating duplicate messages.
03
Local database

What is the main reason a Slack-like mobile app needs a local database instead of only in-memory state?
Options for question 3
1. A. To avoid building backend APIs.
2. B. To restore recent conversations, pending sends, cursors, and unread state.
3. C. To make every message, reaction, thread, and notification strongly consistent across all devices at all times.
4. D. To replace search indexing on the backend.
Correct answer: B.

A mobile app can be killed, backgrounded, or disconnected. Local persistence lets it restore recent conversations, pending sends, cursors, and unread state without waiting for the network.
04
Realtime delivery

How should the system treat WebSockets and push notifications?
Options for question 4
1. A. Use sockets in foreground and push in background, then reconcile through sync.
2. B. Use push notifications for all realtime delivery because mobile operating systems deliver them more reliably than sockets.
3. C. Use WebSockets only for typing indicators and never for messages.
4. D. Use either WebSockets or push, but never both.
Correct answer: A.

Foreground clients can receive low-latency events over WebSockets. Backgrounded mobile clients are constrained by the OS, so push is the wake-up mechanism. Neither path should be the only source of truth, so sync reconciles missed or stale events.
05
Cursors and recovery

What problem does a sync cursor solve in the Slack mobile design?
Options for question 5
1. A. It encrypts locally stored messages and rotates device keys after reconnect.
2. B. It marks the last durable event so reconnect can request newer changes.
3. C. It decides which shard owns a workspace.
4. D. It prevents users from opening the app on multiple devices.
Correct answer: B.

A cursor gives the client a durable recovery point. After reconnect, the client can ask for events after that cursor instead of guessing what it missed.
06
Unread and read state

Which design is best for unread state on mobile?
Options for question 6
1. A. Treat badge counts as exact forever once a push notification arrives, even across devices and reinstalls.
2. B. Update read state locally, send mark-read, then reconcile counts after sync.
3. C. Never cache unread counts locally.
4. D. Use one global unread counter and avoid per-conversation state.
Correct answer: B.

Unread state is user-visible and easy to drift across devices. The mobile app can update locally for responsiveness, but server state and reconnect sync should reconcile the final counts.
07
Files and attachments

Why is file upload usually modeled separately from sending the final chat message?
Options for question 7
1. A. Files do not need permissions once uploaded.
2. B. Reserve metadata, upload bytes, then send a message referencing the file.
3. C. The message service should stream every file through the WebSocket connection so upload and delivery share one path.
4. D. Mobile clients should only support attachments when online and foregrounded.
Correct answer: B.

Separating upload metadata, object storage transfer, processing, and final message creation makes retries and large files easier to handle. It also keeps chat message writes smaller and more predictable.
08
Search

What is the most important correctness requirement for Slack-style search?
Options for question 8
1. A. Search results must be permission-aware.
2. B. Search must always be strongly consistent with the latest message write.
3. C. Search should only index messages opened on mobile so device state and server search stay aligned.
4. D. Search should ignore private channels to simplify indexing.
Correct answer: A.

Search can lag slightly, but it cannot leak private data. Permission-aware indexing and query-time filtering matter more than perfect freshness.
09
Cellular architecture

Why might a large Slack-like system use cells?
Options for question 9
1. A. To isolate workspaces so failures, deploys, and scaling events have smaller blast radius.
2. B. To force every workspace into the same database shard so transaction ordering is simpler for mobile clients.
3. C. To make mobile clients connect directly to databases.
4. D. To avoid queues in the notification pipeline.
Correct answer: A.

Cells split the system into mostly independent slices. If one cell has a problem, other cells can keep serving traffic. That makes the system easier to scale and operate.
10
Fanout tradeoffs

What is the main tradeoff between fanout-on-write and fanout-on-read?
Options for question 10
1. A. Write fanout moves work to send time; read fanout moves work to fetch and sync.
2. B. Fanout-on-write is only for mobile apps, while fanout-on-read is only for desktop apps and workspace exports.
3. C. Fanout-on-write removes the need for storage, while fanout-on-read removes the need for APIs.
4. D. They are the same strategy with different names.
Correct answer: A.

Fanout-on-write precomputes delivery into recipient inboxes or queues, which helps reads but makes writes heavier. Fanout-on-read keeps writes simpler but shifts more work to reads and sync.
11
Failure modes

A user sends a message on flaky mobile data. The server commits it, but the response is lost. What should happen next?
Options for question 11
1. A. Retry with the same idempotency key and reconcile the server-confirmed message.
2. B. Create a new message with a new id on every retry so each network attempt is easy to audit.
3. C. The client should delete the local pending message immediately.
4. D. The server should reject all future retries from that client.
Correct answer: A.

This is exactly why pending local state and idempotent send APIs matter. The retry should map back to the committed server message rather than creating duplicates.
12
Explaining the design

What is the clearest high-level explanation of the Slack mobile architecture?
Options for question 12
1. A. It is mainly a database plus a WebSocket server.
2. B. It is a local-first client backed by storage, realtime fanout, push, sync, search, files, and operations.
3. C. It is a push notification system with message history added later.
4. D. It is an offline app that only syncs when the user manually refreshes.
Correct answer: B.

The point of the post is that the mobile experience is part of the system. A good answer includes local state, durable writes, realtime delivery, push, sync cursors, search, attachments, and operational scaling.

Progress

0/12 answered

Answer every question before submitting.

Made in SF v1

Product EM · SF

01 Home 02 Projects 03 Writing 04 CV 05 Playground 06 Contact

© 2026 Sean Kim