26.8 · A rate limiter, push versus polling, a flight booking app, a swipe deck, an image browser, a ride-hailing rider app and a photo feed API
Seven more design prompts reported in iOS and mobile loops: limiting request rates, choosing how the client hears about changes, a booking flow with timed seat holds, a card-swiping client that must survive a flaky network, an image browser, a ride-hailing rider app and the API behind a photo feed.
Mental model. For each, name the invariant (never exceed the rate, never double-book, never lose a swipe) and the mechanism that keeps it true on a bad network.
Rates, transports and flows
Limiting load, choosing a transport, and modelling a timed workflow.
- Design an API rate limiter, then say how an iOS client should behave under one. Compare token bucket with a fixed window.
Reported at Uber (anonymous, unverified). A fixed window counts requests per time slot (3 per 10 seconds) and resets at the boundary: simple, but a burst… - How does the client learn about new data: polling, long polling, WebSocket, server-sent events or push? How do you choose?
Reported at Meta (anonymous, unverified) for a feed with pushed posts. Short polling (ask every N seconds) is the simplest and works everywhere, but it spends… - Design the client of a flight booking app: search, seat hold, payment and confirmation. How do you handle a timed hold, double taps and a payment that fails?
Reported at Meta (anonymous, unverified). Model the booking as an explicit state machine instead of a set of flags: searching, held (seat and an expiry time)… - Design the client of a Tinder-style swipe app: card prefetching, instant feel, and swipes that must not be lost or duplicated on a bad network.
Reported at Uber (anonymous, unverified). The deck is a local queue with a low-water mark: keep the next several cards (and their images, decoded and… - Design an image browsing app (a grid of photos you can open full screen): thumbnails, paging, caching, memory and offline.
Reported at Google (anonymous, unverified); it builds on the image pipeline in Q327, so here the focus is the whole app. Start with numbers that drive every… - Design the rider app of a ride-hailing service: requesting, matching, a live driver on the map, trip states and a bad network.
Reported for Uber (a search-result summary; the page itself could not be read, so treat it as a typical prompt). Model the trip as a server-driven state… - Design the API behind a photo feed: pagination, response shape, image variants, caching and what the client needs from it.
Reported at Uber (anonymous, unverified). Start with the failure that decides the pagination design: offset paging on a changing list. The user has page one…
More in System design & staff+
- 26.1 · Designing a whole feature: the method, a messenger, an offline reader and a store
- 26.2 · Reliability, payload budgets, and analytics and experiments
- 26.3 · Multi-brand apps and SDKs for other teams
- 26.4 · RFCs and strategy, estimating, incidents and mentoring, and organisation-level bets
- 26.5 · More whole-feature designs: a feed, a video player, a map, search-as-you-type and notifications
- 26.6 · Collaborative editing, a payments ledger and clocks in sync
- 26.7 · Capacity estimates and retry storms