Quiz

Slack client architecture quiz

Check the Slack client architecture post: local truth, state ownership, outbox, push routing, offline UX, accessibility, and client observability.

Questions

12

Est. time

~9 min

Read the post View the series

Score

01
Local source of truth

In the Slack client architecture post, why does the local database sit at the center of the design?
Options for question 1
1. A. It lets every screen render directly from push payloads without repository code.
2. B. It gives the app a durable source of truth for messages, pending sends, cursors, and cached state.
3. C. It replaces the need for server APIs, sync cursors, and realtime repair after a workspace has opened once.
4. D. It guarantees all workspaces are strongly consistent on every device.
Correct answer: B.

The local database is not just a cache. It is the durable place where recent product state, pending mutations, and recovery markers can survive process death and bad networks.
02
State ownership

What should the UI layer do when realtime events, API responses, push-triggered refresh, and outbox retry all update data?
Options for question 2
1. A. Observe screen state from the local store and emit user actions.
2. B. Mutate visible rows directly from whichever update path arrives first.
3. C. Keep separate screen state for API responses, push payloads, realtime events, retries, and background refresh.
4. D. Ignore local state and wait for the next full server snapshot.
Correct answer: A.

A predictable client keeps the UI pointed at derived screen state. The messy update paths write through the data layer, so screens do not each invent their own consistency model.
03
ViewModel or Store

What is the best responsibility for a ViewModel, Observable model, or Store in this architecture?
Options for question 3
1. A. Own product storage, network retries, database migrations, and push tokens directly.
2. B. Map local data into screen state, handle screen events, and call use cases.
3. C. Replace repositories so feature screens can call every API endpoint themselves.
4. D. Persist raw push payloads as the timeline format shown to users.
Correct answer: B.

The state holder should make the screen easy to render and test. It should not become the whole data layer or a place where every update path mutates UI state directly.
04
Durable outbox

Why is optimistic send more than a UI trick?
Options for question 4
1. A. Because the app shows a pending row, persists an outbox record, and retries with the same operation identity.
2. B. Because the app can mark the message sent before writing anything to disk, then rely on memory until restart.
3. C. Because optimistic UI removes the need for server confirmation.
4. D. Because failed messages should disappear when the process is killed.
Correct answer: A.

Optimistic send only feels reliable when the local operation is durable. If the app dies or the network times out, the outbox can resume the same operation later.
05
Idempotency

A send request reaches the server and commits, but the mobile app times out before receiving the response. What should retry do?
Options for question 5
1. A. Create a second message so the user can see both network attempts.
2. B. Retry with a new operation ID and ask the server to guess which pending row should be replaced later.
3. C. Retry with the same idempotency key and reconcile the pending row with the server message.
4. D. Delete the pending row and wait for the user to type the message again.
Correct answer: C.

This is the failure case idempotency is designed for. The same key lets the server dedupe the retry and lets the client reconcile the local pending row.
06
Push routing

How should the app treat a push notification tap?
Options for question 6
1. A. As durable timeline truth because APNs and FCM always include every missing event and exact unread count.
2. B. As a routing hint that must be resolved with workspace context and followed by sync.
3. C. As a reason to clear cached conversation state before opening the app.
4. D. As a direct UI command that bypasses the local database.
Correct answer: B.

Push should route the user to the right destination, not act as the timeline source of truth. The app still needs to resolve workspace context and fetch the latest state.
07
Workspace-scoped navigation

What subtle bug does workspace-scoped routing prevent?
Options for question 7
1. A. Opening the right conversation in the wrong workspace.
2. B. Showing too many messages in the local database after a pagination request, then hiding older history.
3. C. Using a ViewModel instead of a unidirectional data flow store.
4. D. Rendering pending messages before the server confirms them.
Correct answer: A.

Slack-like products have multiple workspaces. A channel or conversation ID is not enough if the destination is scoped to a workspace.
08
Durable vs ephemeral state

Which state most clearly belongs in durable product storage instead of only near the UI?
Options for question 8
1. A. A hover state for a button in a desktop-sized layout.
2. B. A local animation flag for expanding a reaction menu during a single visible interaction.
3. C. A pending message operation that must survive process death.
4. D. A one-frame scroll hint used during a transition.
Correct answer: C.

Pending sends are product state. Losing them after process death would make the app unreliable, so they belong in durable storage.
09
Sync repair

Why does a Slack-like client need sync repair instead of only listening to realtime events?
Options for question 9
1. A. Realtime events can be missed when the app is backgrounded, offline, killed, or reconnecting after a gap.
2. B. Realtime events are only useful for dark mode, accessibility settings, local themes, and one-time UI hints.
3. C. Sync repair is needed only when the backend has no durable message storage.
4. D. It prevents users from opening Slack on web and mobile at the same time.
Correct answer: A.

Mobile clients are interrupted constantly. Sync repair lets the app compare durable cursors, fetch missed changes, and correct stale local state.
10
UX states

Which set of states should be modeled explicitly in the client architecture?
Options for question 10
1. A. Only loading and loaded, because extra states make the UI too complex.
2. B. Cached, syncing, offline, pending, failed, repaired, and permission-lost states.
3. C. Only foreground and background, because the operating system owns everything else.
4. D. Only successful states, because failures should be hidden from users.
Correct answer: B.

Users feel these states directly. Modeling them explicitly makes the app more understandable and gives the design system reusable surfaces for failure, recovery, and progress.
11
Design system boundaries

What belongs in the design system rather than each Slack feature reimplementing it?
Options for question 11
1. A. Workspace membership rules and channel permission decisions.
2. B. Message fanout strategy and shard placement for large workspaces.
3. C. Tokens, typography, error surfaces, skeletons, and accessibility defaults.
4. D. The exact reconciliation rules for every pending message operation and server retry contract.
Correct answer: C.

The design system should make common UI quality repeatable. Feature code still owns product-specific behavior like pending sends, unread dividers, and reaction grouping.
12
Client observability

Which signal would best help the team debug reliability in the Slack mobile client?
Options for question 12
1. A. A count of how often users switch light mode and dark mode.
2. B. Outbox age, retry count, sync repair, push routing, and cold start cache hits.
3. C. The number of SwiftUI or Compose files in the repository.
4. D. A daily count of how many buttons appear on the conversation screen across every breakpoint.
Correct answer: B.

The hard failures are about delivery, recovery, routing, and whether the app can show useful local state quickly. Those signals tell the team where the client feels unreliable.

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