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
  1. 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
  2. 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
  3. 03
    ViewModel or Store

    What is the best responsibility for a ViewModel, Observable model, or Store in this architecture?

    Options for question 3
  4. 04
    Durable outbox

    Why is optimistic send more than a UI trick?

    Options for question 4
  5. 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
  6. 06
    Push routing

    How should the app treat a push notification tap?

    Options for question 6
  7. 07
    Workspace-scoped navigation

    What subtle bug does workspace-scoped routing prevent?

    Options for question 7
  8. 08
    Durable vs ephemeral state

    Which state most clearly belongs in durable product storage instead of only near the UI?

    Options for question 8
  9. 09
    Sync repair

    Why does a Slack-like client need sync repair instead of only listening to realtime events?

    Options for question 9
  10. 10
    UX states

    Which set of states should be modeled explicitly in the client architecture?

    Options for question 10
  11. 11
    Design system boundaries

    What belongs in the design system rather than each Slack feature reimplementing it?

    Options for question 11
  12. 12
    Client observability

    Which signal would best help the team debug reliability in the Slack mobile client?

    Options for question 12
Progress
0/12 answered
Made in SF v1