Case Study: Designing a Chat / Feed Feature

Bringing it all together

This final lesson applies the whole course to a realistic prompt — the kind you’ll face in a senior interview or a real project: “Design the news-feed / chat feature for a mobile app.” The goal is to show a structured way to reason about a mobile feature.

Step 1 — Clarify requirements

• Functional: show a scrolling feed, load more as you scroll, like/comment, work offline, get new items in real time (for chat).
• Non-functional: instant open, smooth scrolling on low-end phones, offline support, low data/battery, secure.

Always state assumptions and scope — interviewers (and teammates) value this.

Step 2 — High-level architecture

Use the layered design from this course:

Step 3 — Data flow (offline-first)

1. The feed list (lazy/recycled) observes the local database — so it shows cached posts instantly, even offline.
2. The repository paginates from the API (cursor-based), writing each page into the DB; the UI updates reactively.
3. Images go through the media pipeline (downsample + cache).
4. For chat, a real-time channel (WebSocket) or push triggers a sync of new messages into the DB.

Step 4 — Handle the hard cases

• Offline likes/messages — write to DB + outbox, sync via a background worker, idempotent so retries don’t duplicate.
• Pagination edge cases — dedupe items (a set of ids), per-page retry, “caught up” state.
• Conflicts — e.g. a like toggled on two devices; choose last-write-wins or server-authoritative.
• Freshness — refresh on open / pull-to-refresh / on push; store last-sync timestamps.

Step 5 — Real-time for chat

For chat, polling is wasteful. Use a WebSocket for a live connection, falling back to push notifications when the app is backgrounded. Incoming messages are written to the DB (source of truth); the UI updates itself. Show optimistic sends (message appears immediately as “sending”, then confirms).

Step 6 — Non-functional concerns

• Performance — lazy list, off-main-thread work, image downsampling, O(1) lookups for “liked” state.
• Security — tokens in secure storage, HTTPS, auth on the socket.
• Monitoring — crash reporting, track feed load time and scroll jank; feature-flag the rollout.

How to present a design

Structure your answer: requirements → high-level architecture → data flow → deep-dive on the tricky parts (offline, pagination, real-time) → non-functional concerns → trade-offs. Talk through why you chose each approach — the reasoning is what’s being assessed.

Common mistakes

• Jumping into UI details before the data architecture.
• Forgetting offline, pagination, real-time and failure cases.
• Not discussing trade-offs (e.g. WebSocket vs push, last-write-wins vs merge).

Summary: Design a feature methodically: clarify requirements, lay out the layered architecture, define an offline-first data flow with pagination and the media pipeline, handle the hard cases (offline writes, conflicts, real-time via WebSocket+push), and cover performance, security and monitoring — always explaining your trade-offs. That structured reasoning is the essence of mobile system design.