Mobile System Design Interview

Prerequisites

Seniority is a weak readiness signal, and a job title is worse. Prerequisite mastery is the signal that works. Answer every Quick check in under a minute. Two or more misses means start with the linked material rather than with Module 1.

Time budget

Learning objectives

Each objective is tested by exactly one numbered item in Section 12, and the numbering matches: objective 1 is tested by item 1, objective 7 by item 7.

1. Classify a mobile prompt inside the first two minutes as client-scope, component or SDK scope, or a server round wearing a mobile title, and state the single sentence that steers a misfiled round without contradicting the interviewer.
2. Derive, for a stated device tier and network profile, a budget set covering cold start in milliseconds, bytes on the wire for the first screen, and peak resident memory, showing each arithmetic step, and name the design option that each number eliminates.
3. Design a paginated and cached list path over a feed that mutates while the user scrolls, naming the pagination scheme chosen and the exact user-visible defect (duplicate, skip or reordering) that each rejected scheme would have produced.
4. Specify an offline write path for a stated connectivity profile, giving the durable queue, the retry policy with jitter, the idempotency key and the conflict rule, and state what the user sees at each of send, retry, conflict and permanent failure.
5. Choose a transport from push, polling, server-sent events, websockets and a persistent broker for a stated update rate and latency need, citing the messages-per-connection-per-hour figure that decides it and the battery cost the rejected option would have carried.
6. Diagnose a described client regression (cold start, dropped frames, memory kill, battery drain, lost upload) into exactly one named cause, and name the single on-device measurement that confirms it, in under three minutes.
7. Rewrite a mid-level mobile answer into a staff-level one by adding version skew across app versions you cannot force-upgrade, a server-side kill switch, one release health metric with its rollback threshold, and one degradation path, annotating what each addition changed about the decision.

Warm-up retrieval

Three to five minutes. Answer out loud or in writing before opening anything. Retrieval beats rereading, and a visible answer converts one into the other.

Q1. From the hub's round router: name two signals inside the first minute that tell you this is a client design round rather than a generalist distributed-systems round.

Q2. From the trade-off atlas on the hub, several pages back: state the decision rule for long polling versus websockets versus server-sent events, and name the number that decides it.

Q3. From the hub's failure library: name the failure class where a fleet of clients all reconnect at the same instant, and give the design change that prevents it.

Module map

+--------------------------------+
| FRAME               M1 to M3   |
| scope, the six axes, budgets   |
| cold start, frames, bytes, RAM |
+---------------+----------------+
                |
                v
+--------------------------------+
| CLIENT SHAPE        M4 to M7   |
| layers, backend for frontend,  |
| networking, pagination         |
+---------------+----------------+
                |
                v
+--------------------------------+   +----------------------+
| DATA IN AND OUT     M8 to M11  |   | THE DEVICE           |
| images, uploads, push and      |==>| M12 storage tiers    |
| transports, the sync engine    |   | M13 battery and life |
+---------------+----------------+   | M14 threads, memory  |
                |                    | M15 platform gaps    |
                |                    +-----------+----------+
                |                                |
                v                                v
+-------------------------------------------------------+
| SHIP AND DEFEND                        M16 to M20     |
| security and privacy, release health and kill         |
| switches, library and SDK design, interview           |
| mechanics, level calibration                          |
+-------------------------------------------------------+

Caption: the five clusters of this course and their reading order.
Frame feeds Client Shape, because you cannot pick an architecture
before you have a budget to hold. Client Shape feeds Data In And
Out, the media, transport and sync work. That cluster feeds The
Device, which is where every one of those choices is paid for in
storage, battery, threads and platform differences. Both feed
Ship And Defend, where mid and staff answers separate. Arrows
point from prerequisite to dependent.

Low ends total 540 minutes, high ends total 720. That is the 9 to 12 reading hours in the time budget above.

The delivery clock for this round

The hub owns the shared clock used across all seven courses. This section is the mobile variant of it, and the shape is genuinely different: fewer minutes on capacity, more on what happens when the network, the OS or the release process takes something away from you. Read the hub's version once; do not read it twice.

The failure this clock is built to prevent is not a missing fact. It is an answer that draws a screen, a view model and a repository, then answers every follow-up inside that picture, never committing to a budget, an offline behaviour, or a plan for the version of the app that is already in the store. That answer can be entirely correct and still leave nothing to score.

The 45 minute round

The phases sum to 45 by construction: 2 plus 6 plus 4 plus 8 plus 9 plus 10 plus 6.

The 60 minute round

These sum to 60: 2 plus 8 plus 5 plus 9 plus 11 plus 16 plus 7 plus 2. The extra fifteen minutes buys a second deep dive and a real operations section. It does not buy more boxes on the client diagram.

The first two minutes

Say four sentences, in this order. Rehearse them once so they are automatic and you can spend your attention on listening.

1. "Let me restate the boundary: the client owns X, the server owes me Y, and the contract between them is Z." (If you cannot fill all three slots, that is your first clarifying question.)
2. "I am going to spend about six minutes on constraints and budgets, then draw the client end to end, then break it on purpose." (You just told them your clock, which reads as control.)
3. "I will assume this has to work with no network and survive the process being killed, unless you tell me otherwise." (Naming those two up front is the cheapest senior signal in this round.)
4. "Stop me if you want depth somewhere specific rather than coverage." (This costs one sentence and gives the other person a cheap way to redirect the round before you have spent ten minutes in the wrong place.)

Declaring what you are skipping

Skipping silently reads as not knowing. Skipping out loud reads as prioritising. The pattern is: name it, say why it cannot change a decision in the next twenty minutes, then say in one sentence what you would do if it were in scope.

• "I am not designing the server's storage layer. Whether the feed is in one shard or fifty does not change anything on the device, and the tight constraint here is bytes on the wire per screen."
• "I am skipping accessibility of the individual cells, which matters and is real work. In scope it would be a focus order, a content description per element and a reflow test at the largest font size."
• "I will not design the analytics schema. Nothing in this client changes based on the event names, because the deciding constraint is the durable queue and its flush policy, and I will design that instead."

Checking in without sounding unsure

A weak check-in asks for approval. A strong one offers a fork.

How the split shifts by level

The rough shape: mid level spends its minutes proving a working client could be built, senior spends them proving each constraint was chosen deliberately, staff spends them proving the design is reachable from the binary that is already installed on millions of devices and survivable when it is wrong.

Module 1. Scope and honesty: what a mobile design round actually tests

Time: 20 to 30 minutes reading, 10 to 15 minutes practice.

1a. Predict first

Five opening lines, all delivered in a slot the recruiter labelled "Mobile System Design".

1b. The four prompt shapes and what each one scores

A mobile design round is not one question type. Four shapes recur, and they reward different behaviour.

The asymmetry that defines this round. A backend design round rewards you for scaling up. A mobile design round rewards you for degrading down. The client is the only node in the system with a human watching it, running on hardware you did not choose, on a network you cannot see, inside a process the operating system may terminate without asking.

The seven things we think this round is actually judging. We cannot publish anyone else's scoring sheet, so this is our own list, derived from the asymmetry above rather than reported from inside a hiring loop. Treat it as a checklist to argue with.

1c. Why some interviewers run a backend round under a mobile title

You cannot control whether this happens to you, and the cost of improvising through it is a third of the round, so a rehearsed script is worth more here than another architecture pattern.

The steering move, in three escalating steps. Use the smallest one that works.

1. The boundary sentence, said once, in the first two minutes. "I will treat the server as one box with a contract on it, and spend most of the time on the device: local storage, sync, rendering and failure. Tell me now if you would rather I go the other way."
2. The split offer, if the follow-ups keep pulling server side. "I can give you ten minutes on how the feed service fans out, or ten minutes on how the client stays correct when that service is slow. Which is more useful to you?"
3. The dual-track answer, if steering fails twice. Answer the server question competently in two minutes, then attach a client consequence to it. "If the fan-out is asynchronous then the client can read its own write before the server has it, so I need a local echo and a reconciliation rule. Here is that rule."

+----------------------------+      +---------------------------+
| DEVICE  33 of 38 minutes   |      | SERVER  5 of 38 minutes   |
| screens and frame budget   |      | one box with a contract   |
| local store and caches     | <==> | shape of the response     |
| outbox and sync            |      | version and compatibility |
| permissions and secrets    |      | push service integration  |
+----------------------------+      +---------------------------+

Figure how a 38 working minute mobile round splits across the boundary

1d. Worked example: the round opens with "Design a photo sharing app"

Forty five minutes, so 38 working minutes after greetings and closing questions. The prompt is one product noun and nothing else.

Block 1. PURPOSE: turn a product name into a surface small enough to design.

I do not ask "what features". That invites a list I cannot fit in 38 minutes. I ask which single user journey we are designing, and I offer three, because offering choices is faster than open questions.

"This product is at least four systems. I can design the feed client, the capture and upload pipeline, or the direct messaging client. Which one do you want?" I get: the feed client, including the images.

The error most readers make here is accepting the whole product and then triaging silently. Triage that happens in your head is invisible, and invisible triage scores as omission.

Block 2. PURPOSE: put the boundary on the record before I draw anything.

I say the boundary sentence from 1c, then I make it concrete: "The server will be one box that returns a page of feed items and signed image URLs. Everything else I say will be on the device."

The interviewer nods. That nod is worth minutes: it is now agreed that I am not evasive about the server, I am scoped.

Block 3. PURPOSE: absorb the first server pull without losing the boundary.

At minute nine the interviewer asks how the feed is ranked. I do not refuse and I do not spend five minutes there.

"Ranking is server side. Assume a scored list per user, recomputed on write plus a request-time blend. What that costs me on the client is that the list is not stable between requests, so my pagination cannot be offset based and my cache key has to include a ranking session. Can I take that consequence and move on?"

Two sentences of server, one sentence of client consequence, and a request to move. This is the dual-track answer used early, before it is needed.

The error most readers make here is either stonewalling ("that is backend") or disappearing into ranking for six minutes. Both cost the same score, for opposite reasons.

Block 4. PURPOSE: pre-commit the two areas that will carry the depth score.

With 38 minutes I get one broad pass and two deep areas, not five. I choose the image pipeline and pagination stability, and I say so out loud at minute twelve: "I am going to go deep on the image memory and cache tiers, and on pagination under a mutating list. I am deliberately not covering direct messages, stories, or the capture pipeline."

The error most readers make here is choosing deep dives implicitly by running out of time in whichever area they happened to reach at minute thirty. Choosing out loud converts a time-out into a decision.

Result. By minute twelve the round has a named surface, an agreed boundary, one absorbed server question, and two declared deep dives. Nothing has been drawn yet, and that is fine: everything drawn after this point is defensible.

1e. Fade the scaffold

Faded example 1. The prompt is "Design a collaborative document editor" in a 45 minute mobile round. Blocks 1 to 3 are given. You produce block 4.

• Block 1: I offer three surfaces (the editor screen, the document list and offline availability, the presence and collaboration layer). I am given the editor plus offline.
• Block 2: I put the boundary on the record. The server is one box exposing document snapshots and an operation stream.
• Block 3: at minute eight the interviewer asks how conflicts are resolved server side. I give two sentences on server-side merge, then the client consequence: local edits must be representable as operations with stable identifiers so that a rebase is possible.
• Block 4: you pre-commit the two deep areas and say what you are skipping.

Faded example 2. The prompt is "Design a ride hailing app" in a 60 minute round with an interviewer from a backend platform team. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: I offer the rider trip screen, the driver client, or the map and location pipeline. I am given the rider trip screen.
• Block 2: boundary stated. The server is one box exposing trip state transitions and a driver location stream.

1f. Check yourself

Q1. Ten minutes into a mobile round, the interviewer has asked three consecutive questions about database replication. You have already used the boundary sentence once. What do you do, and what do you not do?

Q2. You are given the prompt "Design an analytics SDK". Name two things you would design that you would not design for a product surface prompt, and one thing that becomes far more important.

1g. When not to use this

Round triage and boundary setting are cheap, but they are not free and they can be over-applied.

Module 2. Six axes that make mobile different

Time: 25 to 35 minutes reading, 15 to 20 minutes practice.

2a. Predict first

Here is a plan written by a competent backend engineer for a new feature: a live vote count on a video screen.

1 client opens a websocket on screen entry
2 server pushes every vote increment as it happens
3 client updates the number on each message
4 on error client reconnects immediately
5 config for the feature is read from a server flag at app launch
6 rollback plan is revert the server deploy

Figure a server shaped plan for a client feature

2b. The six axes

Every difference that matters in a mobile design round reduces to one of six. Naming the axis out loud in the round is worth more than reciting a platform detail, because it tells the interviewer you have a model rather than a list.

2c. Deployment latency, derived

This is the axis that most changes how a senior candidate answers, so it is worth doing the arithmetic once and carrying the result.

Assume the following, each labelled and each conservative for a large consumer app.

Now the derivation.

• Time until the fix exists on any device: 1 plus 1 plus 5 equals 7 days.
• Time until the fix reaches 90 percent of users: about 30 days from the moment the bug was found.
• A server side fix, from decision to full traffic behind an existing flag: minutes. Take 10 minutes as the working number.
• Ratio of client fix reach time to server fix time: 30 days is 43,200 minutes, divided by 10 equals about 4,300 times slower.
• And the tail never closes. At 3 percent permanently stale and 10 million installs, 300,000 devices run the broken code forever.

The design consequence, stated as a rule. Any behaviour that you might need to change in under a week must be controllable from the server. That is what remote configuration is for, and it is why a kill switch is a design element rather than an operational nicety.

BUG FOUND
   |
   +--> server side path
   |      flag flip  -->  full traffic in 10 minutes
   |
   +--> client side path
          build 1 day > review 1 day > rollout 5 days
             > 60 percent at 7 days > 90 percent at 30 days
             > 3 percent never

Figure the two repair paths available after a bug is found

2d. Worked example: applying the six axes to one feature

The feature: show a live vote count on the video screen, the same feature from 2a. I will pass it through each axis and let each one change the design.

Block 1. PURPOSE: pick the transport by asking what the user can actually perceive, not by asking what is real time.

A human cannot read a number that changes hundreds of times a second. I decide the user needs the count to feel live, which I define as updated at most once per second and correct within a few seconds. That single definition removes the per-event stream.

I choose a server push that carries no payload plus a poll, or a stream that the server already coalesces to one message per second per client. I will take the coalesced stream.

The error most readers make here is treating "real time" as a requirement rather than as a word the product manager used. Ask what interval is perceptible and the whole transport question usually collapses.

Block 2. PURPOSE: make the runtime axis explicit by writing down what happens when the process is not running.

Three states, three behaviours.

The important line is the third. I do not get a reliable callback before termination, so anything I needed to persist must already be persisted. For a read only counter that is trivial. I note it because in module 9 the same axis is what makes an upload queue hard.

Block 3. PURPOSE: bound the render cost so the interaction axis cannot be violated later.

One update per second, one text node changed, on a screen that is also decoding video. The frame budget at 120 hertz is 1000 divided by 120, which is 8.3 milliseconds per frame, and I will reserve a quarter of it for the system compositor and other work, leaving about 6 milliseconds for my code.

A single number update is far inside that. But I add one rule: the update must not trigger a layout pass on the whole screen, because a full layout on a video screen with overlays is the thing that will cost milliseconds, not the text change itself.

The error most readers make here is optimising the network and never asking what the update costs on the main thread. The frame budget is the constraint the user actually feels.

Block 4. PURPOSE: buy back the deployment latency I do not have.

Three server controlled values, read at launch and refreshed on foreground, with safe defaults compiled in.

Defaults compiled into the binary are off, 5 seconds, and poll. If configuration cannot be fetched at all, the app is in its safest state rather than its most expensive one.

The error most readers make here is a kill switch that is only read at cold start. A process can stay alive for days, so the flag must also be re-read on foreground, and the feature must check it at the point of use rather than only at initialisation.

Result. The feature now has a perceptual budget rather than a real time claim, defined behaviour in all three process states, a frame budget rule, and a ten minute off switch. Four of the six axes appear explicitly. Fragmentation and privacy did not bind here, and saying that out loud is itself a scoring move.

2e. Fade the scaffold

Faded example 1. The feature is "show the user's step count from the health sensor on the home screen, updated as they walk". Blocks 1 to 3 are given. Produce block 4.

• Block 1: perceptible interval is coarse. A step count that updates every 10 to 30 seconds is indistinguishable from one that updates continuously, so I read a batched aggregate rather than subscribing per step.
• Block 2: runtime. The process is usually not running while the user walks, so the sensor data must be recorded by the operating system's own store and read on foreground, not accumulated in my memory.
• Block 3: interaction. One text update per 10 seconds is free. No frame budget concern.
• Block 4: you handle the remaining two axes.

Faded example 2. The feature is "let the user reply to a message directly from the notification". Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: there is no perceptible interval question. The interaction is a single user initiated send.
• Block 2: runtime. The reply is handled in a short lived, restricted execution context that the operating system grants for a limited window, and the main app process may not be running at all.

2f. Check yourself

Q1. Using the assumptions in 2c, a bug is found on day zero that corrupts a local cache. The team ships a client fix immediately. On day 10, roughly what fraction of the installed base is still running the broken code, and what does that imply about the server side of the fix?

Q2. Which single axis explains why an "immediate reconnect on socket error" loop is worse on mobile than on a desktop web client? Name the two distinct costs.

2g. When not to use this

The six axis pass is a framing tool. It is a checklist, and checklists get recited.

Module 3. Non-functional requirements with budgets

Time: 35 to 45 minutes reading, 20 to 30 minutes practice.

3a. Predict first

Here is a non-functional requirements block a candidate wrote in a real-shaped round.

NON FUNCTIONAL REQUIREMENTS
  app should start fast
  scrolling should be smooth
  should not use too much memory
  should work on low end devices
  should be battery efficient
  should work offline

Figure a requirements block with no design consequence

3b. Tiers, cold start and the frame budget

Device tiers, because a number without a tier is meaningless

Every budget in this module is per tier. Define the tiers first, in the round, in about twenty seconds.

The rule that follows. Budgets are set at the tier boundary you commit to, not at the average. If you support the low tier, the low tier number is the requirement and the high tier number is a bonus. Averages hide the users who churn.

Cold start, decomposed until it sums

Two terms, defined before use.

Where the targets come from. Use the classic response time thresholds from Nielsen, Usability Engineering (Academic Press, 1993): about 0.1 seconds feels instantaneous, about 1 second keeps the user in flow, and about 10 seconds loses their attention entirely. Those are perception facts, not platform facts, so they are a legitimate basis for a target.

Now decompose the mid tier budget so it sums. A target you cannot attribute is a target you cannot defend when it regresses.

What this table buys you in the round. Three separate arguments, all derivable from it.

• The 250 millisecond library budget is the whole reason lazy initialisation is an architecture decision rather than a micro-optimisation. Ten libraries at 25 milliseconds each consumes it entirely.
• The 200 millisecond disk read is why the design must render from cache first and reconcile with the network afterwards. If you wait for the network you have spent 400 of your 600 remaining milliseconds on a resource you do not control.
• On the low tier, assume every phase is roughly 1.6 times slower (2.5 divided by 1.5 from the target table). 900 milliseconds of initial display becomes about 1,440, which is exactly the low tier target, with no slack. That is how you show the interviewer that the low tier is not an afterthought.

The frame budget, and why 60 hertz thinking is now wrong

The refresh rate sets a hard deadline. Miss it and the previous frame is shown again, which the user perceives as a stutter.

The consequence, derived. Take a single main thread operation that costs 8 milliseconds, for example parsing a moderate JSON payload on the main thread.

• At 60 hertz it consumes 8 divided by 12.5 equals 64 percent of the budget. Tight but survivable.
• At 120 hertz it consumes 8 divided by 6.2 equals 129 percent of the budget. Every frame it runs in is dropped.

So the same code is acceptable on a 2018 device and janky on a 2024 flagship. This inverts the usual intuition that newer hardware forgives more, and it is worth saying out loud in a round.

Jank arithmetic. A 100 millisecond main thread block at 120 hertz drops 100 divided by 8.3, which is about 12 consecutive frames. Users reliably perceive anything above roughly two dropped frames during a scroll or animation, so a single 100 millisecond block is not a small problem.

120 HERTZ FRAME  8300 microseconds per frame

+-------------------------------------+--------+
| application work  6200 microseconds | system |
+-------------------------------------+--------+
0                                  6200     8300

one main thread parse of 8000 microseconds
+------------------------------------------+
| overruns the budget so the frame is lost |
+------------------------------------------+

Figure the application share of a 120 hertz frame and one overrun

3c. Memory, bytes per screen and battery

Memory, and the kill you cannot catch

Two numbers matter and they are different.

Bitmap arithmetic, because images dominate. A decoded bitmap costs width times height times bytes per pixel. At 4 bytes per pixel (8 bits each for red, green, blue and alpha):

• A full screen image at 1080 by 2400 pixels: 1080 times 2400 times 4 equals 10,368,000 bytes, about 10.4 megabytes.
• A 12 megapixel camera photo at 4000 by 3000: 4000 times 3000 times 4 equals 48 megabytes decoded, from a source file that might be 3 megabytes on disk.
• Assume a 192 megabyte heap cap on a mid tier device. That is 192 divided by 10.4, about 18 full screen bitmaps, and exactly 4 camera photos before you are dead.

The gap between a 3 megabyte file and a 48 megabyte decode is the single most important number in module 8, and it is why "the image is small" is never an answer.

Why footprint matters even when you never crash. When memory is scarce the system reclaims it by terminating background processes, and larger processes are reclaimed first. So an app with a large footprint is killed while backgrounded and pays a full cold start on return.

Derive the user visible cost with the module 3c numbers: a warm resume renders in roughly 200 milliseconds (screen recreation only), a cold start costs 1,500 milliseconds on mid tier. That is a 7.5 times penalty, and the user attributes it to the app being slow, not to memory.

A defensible budget block for a feed screen, mid tier.

Bytes per screen, and the battery cost of a chatty client

Bytes per screen, derived for a feed. Assume a feed screen shows 8 cards, each with one square image, on a device with a 1080 pixel wide display.

The elimination this performs: 13 seconds to fill a screen is not a slow experience, it is an abandoned session. So serving one image size for all surfaces is ruled out, and the design needs server side variants keyed by the rendered size. That is a requirement, derived, in four lines.

Battery, taught as a mechanism rather than an invented milliwatt figure. The dominant client controllable cost is the radio, because of tail energy: after a transmission the radio stays in a high power state for a few seconds before stepping down, in case more data arrives.

Assume a 5 second tail and 1 second of active transmission per request. This is a modelling assumption; the exact tail is network and generation dependent, but the existence of a multi-second tail is the mechanism that matters.

• Ten requests spaced 20 seconds apart: each pays 1 second active plus 5 seconds tail, so 10 times 6 equals 60 radio-seconds.
• The same ten requests coalesced into one burst: 2 seconds active plus 5 seconds tail equals 7 radio-seconds.
• Ratio: about 8.6 times less radio time for identical payload.

That single derivation justifies request coalescing, batched telemetry, and deferring non-urgent work to a moment when the radio is already awake. It is also why a background poll every 60 seconds is one of the most expensive things a mobile app can do.

Relative subsystem cost, ordered rather than numbered. Continuous location at high accuracy and continuous camera or video encoding sit at the top, sustained radio use next, then screen at high brightness, then general processing. Any absolute number here would be device specific and would age badly, so what you state in a round is the ordering plus the measurement you would run: an on-device power profile with the feature on and off, on the same device, at the same brightness.

3d. Worked example: writing the budget block for a prompt in three minutes

The prompt: "Design the client for a short video feed." I have about three minutes of my 38 for non-functional requirements, and I want every line to eliminate something.

Block 1. PURPOSE: commit to a tier before any number, so the numbers are measurable.

I say: "I will design for the mid tier as the default and treat the low tier as a supported degradation, assuming a global consumer distribution. If this is a market where the low tier is the majority, tell me and I will move the budgets."

The error most readers make here is quoting a single number with no tier attached. It is not wrong, it is unfalsifiable, and unfalsifiable numbers score as decoration.

Block 2. PURPOSE: set the three budgets that will actually constrain the architecture.

Each of these is one of the derivations above, restated for this prompt. Nothing new was invented.

Block 3. PURPOSE: convert the byte budget into a product decision the interviewer can push back on.

Using the byte arithmetic in 3c: at 1 megabit per second, 1.5 seconds of budget buys about 190 kilobytes. So the first video segment must be under roughly 150 kilobytes after protocol overhead, which forces a low bitrate initial segment and an adaptive ladder that steps up after playback starts.

I say the consequence out loud: "This means the first two seconds of video will visibly be lower quality on a slow connection, and I am choosing that over a spinner. That is a product trade-off and I would want it confirmed."

The error most readers make here is presenting a technical budget without surfacing the product consequence. The budget is only interesting because it forces someone to choose between a blurry start and a blank screen.

Block 4. PURPOSE: name the battery budget in a way that can be checked.

Continuous video decode plus sustained network is close to the worst combination a phone can run, so I do not promise a number I cannot derive. I promise a method: "I would set the budget as a percentage of battery per hour of active viewing, measured on a fixed device at fixed brightness, and treat a regression above a set threshold as release blocking. I would also add a low power mode behaviour: drop the prefetch depth from three items to one and cap the bitrate ladder."

The error most readers make here is inventing a milliwatt figure. Stating the measurement and the degradation policy is stronger than a number you cannot defend, because the measurement survives a follow-up question and the invented number does not.

Result. Four budgets, each attached to a tier, each ruling out at least one design option, and one of them explicitly handed back to the product as a trade-off. That block takes about three minutes to say and it makes every later decision in the round defensible.

3e. Fade the scaffold

Faded example 1. The prompt is "Design the client for a map application". Blocks 1 to 3 are given. Produce block 4.

• Block 1: I commit to the mid tier, and I note that maps are used outdoors where the network is worst, so I will use a 0.5 megabit per second assumption rather than 1.
• Block 2: budgets are time to first map tile under 1.2 seconds from a cached region, 6 milliseconds of application work per frame during a pan, and 200 megabytes resident with tiles included.
• Block 3: byte budget. At 0.5 megabits per second, 1.2 seconds buys about 75 kilobytes, which is roughly three vector tiles at an assumed 25 kilobytes each, so the first view must be served from the on-device tile cache and the network path is for the surrounding ring only.
• Block 4: you write the battery budget and the degradation policy.

Faded example 2. The prompt is "Design a messaging client". Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: mid tier default, and I flag that messaging is used on every tier including the oldest devices, so the low tier is a first class target rather than a degradation.
• Block 2: time to conversation list under 1.0 seconds cold on mid tier, because the list must come entirely from local storage; 6 milliseconds per frame at 120 hertz while scrolling a conversation; 150 megabytes resident.

3f. Check yourself

Q1. Your feed screen currently does a 5 millisecond main thread JSON parse per card as cards come into view. The team ships a device with a 120 hertz display. Nothing in your code changed. Using the frame budget table in 3b, quantify what happened and name the fix that does not require making the parse faster.

Q2. A reviewer says your 24 megabyte image cache budget is arbitrary. Defend it from stated inputs, then state the condition under which you would change it.

3g. When not to use this

Budget blocks are the highest value three minutes in a mobile round, and they are still possible to over-apply.

Module 4. Client architecture

Time: 35 to 45 minutes reading, 20 to 25 minutes practice.

4a. Predict first

Here is the responsibility list of one screen class, taken from a real shaped codebase.

FeedScreen
  holds   the list of items currently shown
  does    fetch a page from the network
  does    parse the response
  does    decide which items are advertisements
  does    write items to the local database
  does    handle pull to refresh
  does    handle a like tap and post it
  does    format timestamps for display
  does    emit analytics events
  does    show error alerts

Figure one screen class holding ten responsibilities

4b. Layers, and the one rule that makes them real

Three layers, defined before use, with an explicit dependency direction.

The rule that makes layering more than folder names. Dependencies point inward only. Presentation may depend on domain. Data may depend on domain. Domain depends on nothing. If the domain layer imports a view type or a network type, the layering is decorative.

Why this matters more on a client than on a server. A server process usually handles one request and exits the code path. A client holds live state across a user session that spans minutes, survives configuration changes, and must be restorable after the process is killed. State without an owner outside the view is the root cause of most client bugs.

The user interface pattern family, and where each one stops

Four points on a spectrum. Each is a legitimate answer at some size, and each has a specific breaking point. Naming the breaking point is what separates a senior answer from a pattern name.

The rule that fixes the middle two. The view is a function of one state value. If two pieces of state can disagree, make them one piece of state with a shape that cannot express the disagreement. A sealed set of states (Loading, Empty, Content with items, Error with a reason) makes "spinner visible and content visible" unrepresentable rather than merely unlikely.

The fix for the fourth. Do not abandon the single state. Slice it. The view subscribes to the derived slice it needs, and rerender is scoped to the slice that changed. This is a memoisation problem, not an architecture problem.

Unidirectional data flow

Three terms, defined before use.

The loop, and the reason effects are separated from the reducer: a reducer that performs a network call is not testable without a network, and a reducer that returns a description of a network call is testable with an equality assertion.

     +--------+   event    +----------+   effect   +---------+
     |  VIEW  | =========> | REDUCER  | =========> | EFFECTS |
     |        |            | pure     |            | network |
     |        | <========= | function |            | storage |
     +--------+   state    +----------+            +---------+
                                |                        |
                                +<=======================+
                                    result event

Figure the unidirectional loop with effects outside the pure reducer

Dependency injection, priced against the cold start budget

Dependency injection means an object receives its collaborators rather than constructing or locating them. Three ways to do it, priced against the 250 millisecond library and graph budget from module 3.

The derivation that decides it. Assume a reflective container resolves a binding in 0.2 milliseconds on a mid tier device. This is a modelling assumption; measure yours. With 400 bindings resolved eagerly at launch, that is 400 times 0.2 equals 80 milliseconds, which is 32 percent of the entire 250 millisecond library budget from module 3, spent on wiring rather than on anything the user asked for.

Two consequences, both worth stating in a round.

• Prefer a graph resolved at build time, because the cost then lands on your build machine rather than on the user's cold start.
• Make everything lazy by default. A binding that is never used on the launch path should cost nothing at launch, whichever approach you chose.

Modularisation, and the threshold where it pays

Splitting an application into build modules buys three things: parallel and incremental builds, enforced dependency direction (a module simply cannot import what it does not declare), and ownership boundaries that survive team growth.

It costs configuration, a public and internal split for every type crossing a boundary, and a new class of problem where a change requires touching four modules.

The threshold, derived from build time. Assume a full build takes 8 minutes, an engineer makes 20 incremental builds a day, and a single module incremental build takes 45 seconds against 4 minutes for a monolithic incremental build.

• Saving per build: 4 minutes minus 45 seconds equals about 3.25 minutes.
• Per engineer per day: 20 times 3.25 equals 65 minutes.
• With 3 engineers: about 3 hours a day recovered, which pays for the modularisation work within weeks.
• With 1 engineer: about 1 hour a day, and the boundary maintenance cost is now a meaningful fraction of the saving.

So the honest threshold is roughly three or more engineers touching the same codebase daily, or a monolithic incremental build already over about two minutes. Below that, modularise to enforce layering only if you have already seen the layering violated.

4c. The layered picture, with state ownership marked

+---------------------------------------------------------+
| PRESENTATION   views  gestures  one state object         |
+---------------------------------------------------------+
              |  events go down and state comes back up
              v
+---------------------------------------------------------+
| DOMAIN   use cases  entities  invariants  no platform    |
+---------------------------------------------------------+
              |  calls go down and results come back up
              v
+---------------------------------------------------------+
| DATA   repository owns the truth  remote and local       |
+---------------------------------------------------------+
              |
              v
+-------------------+       +-----------------------------+
| REMOTE SOURCE     |       | LOCAL SOURCE  database      |
+-------------------+       +-----------------------------+

Figure three layers with dependencies pointing inward and truth in data

4d. Worked example: one screen, three asynchronous sources

The screen is a feed. Three sources feed it: a cached page from the local database, a network refresh, and a live stream of like counts. The user can also like a post, which is a write.

Block 1. PURPOSE: name the single source of truth before naming any pattern.

I ask one question of the design: after a like, which component holds the answer to "is this post liked"? If the answer is "the screen", I have the 4a bug. If the answer is "the repository", every screen showing that post agrees for free.

So the repository owns item state and exposes it as an observable query over the local database. The network writes into the database. The screen reads only from the database. The network never talks to the screen.

The error most readers make here is choosing a presentation pattern first. The presentation pattern is downstream of where the truth lives, and if the truth lives in the view, no pattern rescues it.

Block 2. PURPOSE: collapse three asynchronous sources into one state so an impossible screen cannot be rendered.

Three independent observables can produce a frame where refreshing is false, items is empty and error is null, which is a blank screen with no explanation. I make the state one sealed value instead.

Note that Content carries isRefreshing rather than there being a separate refreshing flag. That is the whole trick: refreshing is only meaningful when there is content, so the type says so.

The error most readers make here is keeping a boolean per concern because it is easy to write. The cost arrives later as a bug report with a screenshot nobody can reproduce.

Block 3. PURPOSE: model the optimistic write as a state, not a mutation.

A like tap must feel instant, so I write it locally first. But a local write that is indistinguishable from a confirmed one is a lie the user will eventually catch.

So the database row carries the like value plus a pending marker. The repository exposes the merged view (local value wins), and the outbox owns the send. Three outcomes.

Block 4. PURPOSE: pick the injection and module boundary from the test I want to be able to write.

The test I want: give the domain layer a fake repository, apply a like event, assert the emitted state sequence, with no platform runtime and no database. That test is only possible if the use case depends on a repository interface, not a class.

So: constructor injection of an interface, the implementation bound in a data module, the domain module depending on nothing. With three engineers on this codebase, the modularisation threshold from 4b is met, so I split presentation, domain and data into build modules and let the build enforce what a code review otherwise has to.

The error most readers make here is introducing interfaces everywhere as a reflex. An interface earns its place when it has a second implementation, and a fake used in a test is a legitimate second implementation. An interface with exactly one implementation and no test double is overhead.

Result. The truth lives in one place, the screen cannot render an impossible combination, the optimistic write is honest about its own uncertainty, and the architecture is justified by a test rather than by a diagram.

4e. Fade the scaffold

Faded example 1. The screen is a chat conversation: a local message history, an incoming message stream, a typing indicator stream, and an outgoing send. Blocks 1 to 3 are given. Produce block 4.

• Block 1: truth is the local message database. Incoming messages are written to it, never delivered to the view directly.
• Block 2: one sealed state. Content carries messages, a connection banner value, and the typing indicator, because a typing indicator is only meaningful with content on screen.
• Block 3: an outgoing message is inserted immediately with status Pending, moves to Sent then Delivered, or to Failed with a retry affordance.
• Block 4: you choose the injection approach and the module boundaries, justified by a test.

Faded example 2. The screen is a photo picker: the device photo library, an in-progress selection, and an upload triggered on confirm. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: truth for the library is the operating system's own photo store, which I query but do not copy. Truth for the selection is a state holder scoped to the picker flow, not to a single screen.
• Block 2: one sealed state with PermissionRequired, Loading, Content carrying a page of asset references plus the selected set, and Denied carrying whether the denial is permanent.

4f. Check yourself

Q1. A colleague proposes exposing four separate observable values from the state holder: items, isLoading, errorMessage and isEmpty. Give the concrete failing frame this permits, and the smallest change that makes it impossible rather than unlikely.

Q2. Your team has one engineer, a 90 second incremental build and 40 wired types. A reviewer says the app should be split into eight modules with a generated dependency graph. Using the thresholds in 4b, what do you say?

4g. When not to use this

The layered plus unidirectional design is a good default, and defaults get applied where they do not pay.

Module 5. Backend for frontend for mobile

Time: 25 to 35 minutes reading, 15 to 20 minutes practice.

5a. Predict first

Here is a feed response and the client code that consumes it.

GET  feed  returns
  items
    id
    author id
    author name
    text
    media key
    ranking score
    experiment bucket
    flags bitmask

client
  if appVersion is 3 or higher
      build image url with layout v2
  else
      build image url with layout v1

Figure a response that leaks the server model and a version ladder

5b. The placement rule, derived rather than asserted

There is one rule, and it falls straight out of module 2c.

Anything you might need to change in less than a week belongs on the server. Anything that must work with no server belongs on the client.

Apply it, and most placement arguments resolve without opinion.

What a backend for frontend actually is. A service that exists to serve one client family, sitting in front of the domain services, owned by the client team, and free to change shape as fast as the client needs. It is not a gateway and it is not a caching layer, though it may do both.

The one honest reason it exists. Domain services are shared and therefore slow to change. Client screens are unshared and change constantly. Putting the fast changing shaping code behind an interface the client team owns is the whole idea.

5c. Response shaping, as a spectrum with a version skew cost

Four levels. Each is correct somewhere. The cost that rises down the list is version skew: the number of app versions in the wild that must all correctly render whatever the server sends.

When not to use each, stated plainly.

• Level 0 when not: when a screen needs six calls to render, because each call costs a round trip. On a 150 millisecond cellular link, six sequential calls is 900 milliseconds of pure latency, which is most of the 1.5 second budget from module 3.
• Level 1 when not: when three different screens need almost the same data. You end up with three near duplicate responses and a shaping service that changes on every screen tweak.
• Level 2 when not: when you have fewer than roughly two years of supported client versions or no real need to reorder remotely. The renderer, the unknown component handling and the analytics plumbing are weeks of work, and they buy flexibility you are not using.
• Level 3 when not: almost always for a general product surface. You are rebuilding a layout engine over a network, you lose platform accessibility behaviour unless you reimplement it, and every rendering bug becomes a data bug that you cannot reproduce locally.

The rule that makes level 2 survivable. Unknown component types must be skipped silently and counted, never rendered as an error and never crashed on. The count is the important half: without telemetry on skipped components, a server change that strands 20 percent of clients is invisible.

5d. Worked example: shaping the feed response across three live app versions

The situation: versions 8.0, 8.1 and 8.2 are all in the wild, holding roughly 15, 25 and 60 percent of traffic. 8.2 shipped a new card type with a video preview. The product wants to launch a poll card next week.

Block 1. PURPOSE: replace version numbers with capabilities, so the server stops guessing.

The client sends what it can render, not what it is. One header or field at request time.

client sends
  supported cards   text  photo  video  poll
  supported media   avif  webp  jpeg
  screen width dp   412
  pixel density     3
  locale            en GB
  low data mode     false

Figure a capability declaration replacing a version number ladder

Now the server never needs a version table. A client that does not know polls simply does not list poll, and it is not sent one. When 8.3 adds polls, the same server code serves it with no change.

The error most readers make here is sending the app version and building the capability mapping on the server. That works until a version is hotfixed, or a build is region specific, or a client disables a feature at runtime because a flag turned it off. Capabilities are a property of the running client, and versions are only a proxy for them.

Block 2. PURPOSE: choose a shaping level for this specific screen, and say what it costs.

The feed needs remote reordering and new card types without releases, so this is level 2, a typed component list. I say the cost out loud rather than pretending it is free.

That third row is the one that separates a considered answer from an enthusiastic one. Whole page parsing of a heterogeneous list is the most common way this design fails in production.

Block 3. PURPOSE: write the compatibility rules as rules, so they can be reviewed.

Five rules, and the whole contract discipline is in them.

1. Fields are added, never removed and never repurposed. A field name means one thing forever.
2. Enumerated values are open. Every client ships a default case, and the server does not send a new value until the population that has the default case is large enough (see block 4).
3. Nothing server internal crosses the boundary. No ranking scores, no experiment names, no internal identifiers with meaning.
4. Cursors and tokens are opaque strings. The client stores and returns them and never parses them.
5. Every response carries a server supplied schema or configuration version, so telemetry can attribute a rendering bug to a server change rather than a client release.

The error most readers make here is treating "additive only" as the whole policy. Additive only is necessary and insufficient. Rule 2 is the one that actually bites: adding a value to an existing enumeration is additive and it still breaks every client that has an exhaustive switch on it.

Block 4. PURPOSE: decide when it is safe to send the new thing, using the adoption curve.

The poll card requires clients to declare the poll capability, which lands in 8.3. From module 2c: about 60 percent of users are on the newest version at 7 days after availability and 90 percent at 30 days.

I choose substitution, because a feed with a hole in it is a worse product than a feed with an older card type, and because substitution is the mechanism that lets us stop caring about the 3 to 5 percent who never upgrade.

The error most readers make here is planning around a forced upgrade. Compute the cost first: at 10 million installs and a 3 percent permanent tail, forcing an upgrade below 8.3 strands 300,000 users. Forced upgrade is a security tool, not a product convenience.

Result. The server no longer knows or cares about app versions, the shaping level is chosen with its costs named and mitigated, five reviewable compatibility rules exist, and the launch plan is built from the adoption curve rather than from hope.

5e. Fade the scaffold

Faded example 1. The surface is a settings screen whose rows differ by account type, region and several experiments. Blocks 1 to 3 are given. Produce block 4.

• Block 1: capabilities. The client declares which row control types it can render (toggle, chooser, link, destructive action) and its accessibility text scale.
• Block 2: shaping level 2, a typed list of rows, chosen because settings composition changes constantly and per region, and because a settings screen is exactly a list of typed components.
• Block 3: the five rules apply unchanged, with one addition: a destructive row must carry a server supplied confirmation string, so a new destructive action can never ship without its warning.
• Block 4: you decide the rollout plan for a new row control type.

Faded example 2. The surface is a checkout screen. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: capabilities are the available payment method types, the supported authentication challenge types, and whether the client can present a web view for a redirect flow.
• Block 2: shaping level 1, a screen shaped view model, deliberately not level 2. Checkout has a small, slow changing set of surfaces and a high correctness bar, and a generic renderer makes correctness harder to reason about.

5f. Check yourself

Q1. A teammate proposes returning displayPrice: "£12.99" from the server so that all clients format identically. Give two concrete failures, and state the one case where their proposal is actually right.

Q2. You are on shaping level 2 and telemetry shows 4 percent of sessions skipping at least one component. Name the two most likely causes and the different fix for each.

5g. When not to use this

A backend for frontend is a service, with a team, an on-call rotation and a deployment pipeline. That is a real cost.

Module 6. Networking under constraint

Time: 35 to 45 minutes reading, 20 to 30 minutes practice.

6a. Predict first

Here is the network configuration of a real shaped client.

request timeout        30 s
max retries            5
backoff                1  2  4  8  16 s
retry on               any failure
concurrent requests    unlimited
deduplication          none
idempotency keys       none

Figure a network configuration with four independent defects

6b. Protocol choice, priced in round trips

Three terms first. Round trip time is one message to the server and back. Head of line blocking is one stalled item preventing later items from being processed. Connection migration is a connection surviving a change of network interface or address.

The handshake arithmetic that decides connection reuse. Assume a 150 millisecond round trip time on a mobile network, which is a reasonable middle for cellular.

Now apply it. A screen that makes 4 sequential calls, each on a fresh connection, spends 4 times 300 equals 1,200 milliseconds on handshakes alone, which exceeds the entire 900 millisecond initial display budget from module 3. The same 4 calls on one reused multiplexed connection spend 0.

That derivation eliminates two designs at once: it rules out one connection per request, and it rules out sequential dependent calls where a single shaped response would do (which is the argument that module 5 made from the other side).

The mobile specific point worth saying out loud. A phone changes network interface mid session, walking out of a building from wifi to cellular. A connection identified by an address dies at that moment and every in-flight request fails. A connection identified by a connection identifier can migrate and survive. That is not a micro-optimisation, it is the difference between a visible failure and no event at all, and it happens to every user every day.

6c. Quality of service tiers, retries, and deduplication

Tiers, because a single queue makes the user wait for the prefetcher

Define the tiers by who is waiting, then give each its own limits.

The derivation that justifies separate pools. Assume one shared pool with 4 concurrent slots, and 20 opportunistic prefetches already queued, each taking 200 milliseconds.

• Time to drain the queue: 20 divided by 4, times 200 milliseconds, equals 1 second.
• So a user tap can wait up to 1 second before its request even starts, on top of its own latency.
• With separate pools, the user blocking tier has its own 4 slots and starts immediately.

One second of pure queueing is worth roughly the entire first render budget from module 3, which is why this is an architecture decision and not a tuning knob.

The retry taxonomy

Retrying the wrong thing is worse than not retrying.

Full jitter, and why it is not optional. The rule is: wait a random duration between zero and the current backoff ceiling, rather than waiting the ceiling.

Derive the effect. Assume 10,000 clients failed during the same incident, and the fourth backoff step has a ceiling of 8 seconds.

• Without jitter, all 10,000 retry within the same few tens of milliseconds. The recovering server sees an instantaneous 10,000 request spike.
• With full jitter over an 8 second window divided into 100 millisecond buckets, there are 80 buckets, so the expected arrivals per bucket are 10,000 divided by 80, which is 125.
• That is an 80 times reduction in peak, from arithmetic alone, with no coordination between clients.

The retry budget, which is the tier most designs leave out. Cap retries as a fraction of successful requests over a rolling window, for example 10 percent. When the budget is exhausted, fail immediately without retrying.

Why: during a total outage there are no successes, so the budget is zero, so clients stop retrying entirely. Without a budget, a full outage means every client sends 1 attempt plus 5 retries, which is 6 times normal load aimed at a server trying to come back. The budget converts a self-inflicted denial of service into a graceful stop.

Deadlines beat retry counts. Give the operation a total budget and let it fit as many attempts as it can.

Worked: a 10 second user deadline, 1 second base backoff, doubling, with a 2.5 second per attempt timeout. Attempt 1 at t equals 0, fails at 2.5. Backoff up to 1 second, attempt 2 at about 3.5, fails at 6. Backoff up to 2 seconds, attempt 3 at about 8, must complete by 10. So three attempts fit, and the fourth is not started because it cannot finish. The user is told at 10 seconds, not at 211.

Deduplication, coalescing and idempotency

Three different mechanisms that are often confused.

Coalescing, quantified. On a feed screen with 8 cards by 3 distinct authors, naive avatar loading issues 8 requests. Coalescing on the signature (method, path, sorted query, body hash) collapses them to 3, a 62 percent reduction, with no cache and no server change.

Idempotency keys, and the one rule that makes them work on mobile. The key is generated when the operation is created, not when the request is sent, and it is stored with the operation in durable storage.

The reason is module 2's runtime axis: if the key is generated at send time, a process killed between two send attempts generates a new key on relaunch, and the server sees two distinct operations. A key persisted with the operation survives process death, which is the only case that matters.

The request pipeline

+-----------+   +-------------+   +---------------+
| CALL SITE |==>| DEDUPE      |==>| TIER QUEUE    |
| use case  |   | in flight   |   | blocking 4    |
|           |   | map by sig  |   | visible   4   |
+-----------+   +-------------+   | deferrable 2  |
                                  | opportunist 2 |
                                  +---------------+
                                          |
                                          v
+-------------+   +-------------+   +---------------+
| RESULT      |<==| RETRY       |<==| CONNECTION    |
| or typed    |   | taxonomy    |   | pool reused   |
| error       |   | jitter      |   | multiplexed   |
+-------------+   | budget      |   +---------------+
                  +-------------+

Figure the path of one request through dedupe tier retry and pool

6d. Worked example: the network path of a like tap

The operation: the user taps like. It must feel instant, must not double apply, and must survive the app being killed.

Block 1. PURPOSE: classify the operation before choosing any policy, because the tier decides everything else.

Is the user waiting on the network? No. Module 4's optimistic write already put the like on screen from local state. So this is not user blocking, it is deferrable: it must eventually happen, and nobody is watching the clock.

That single classification gives me the concurrency limit (2), the timeout (30 seconds), the retry policy (until success with a cap), and the low power behaviour (defer). None of those were separate decisions.

The error most readers make here is classifying by importance rather than by who is waiting. A like is important and nobody is waiting for it. A prefetch is unimportant and nobody is waiting for it. Importance decides how hard you retry, waiting decides the queue.

Block 2. PURPOSE: make the operation durable and identified before it is allowed near the network.

Order matters and it is counterintuitive: persist first, send second.

1. Write the intent to the outbox table: entity identifier, desired value, a generated idempotency key, created timestamp, attempt count, state Pending.
2. Update the local item so the interface shows the like.
3. Only then enqueue a send.

If the process dies between steps 1 and 3, the outbox still holds the intent and the send is retried on relaunch with the same key. If the key had been generated at step 3, the relaunch would generate a second key and the server would see two likes.

The error most readers make here is generating the identifier in the network layer. It looks like a networking concern and it is a durability concern.

Block 3. PURPOSE: derive the retry policy from a deadline instead of picking a retry count.

A like has no user deadline, but it does have a usefulness horizon. I set 24 hours: after that, the intent is stale enough that silently dropping it is better than applying it.

The connectivity gate is what makes this cheap. From the retry taxonomy, no route means do not attempt, so a device offline for 8 hours performs zero attempts rather than 32 wasted radio wakes.

Block 4. PURPOSE: handle the rapid double tap, which is a deduplication problem and not a retry problem.

The user taps like, unlike, like within a second. Three intents, one final truth.

The outbox is keyed by (entity identifier, operation type), not by intent instance. A new intent for the same key replaces the pending row rather than appending to it, provided the existing row has not started sending. If it has started, the new intent is queued behind it and the idempotency key is regenerated, because it is genuinely a second operation.

The result: three taps produce one request in the common case, and never produce an inconsistent final state.

The error most readers make here is treating this as debouncing in the interface. A debounce on the button hides the symptom and does nothing for a tap on one screen followed by a tap on a duplicate of that screen, or for two intents that survive a process restart. The collapse belongs in the durable queue.

Result. One classification decision produced four policies, durability came before transmission, the retry policy came from a stated horizon rather than a habit, and the double tap was solved where the state lives rather than where the finger lands.

6e. Fade the scaffold

Faded example 1. The operation is prefetching the next screen of feed images. Blocks 1 to 3 are given. Produce block 4.

• Block 1: nobody is waiting, and it is not important, so this is opportunistic: 2 concurrent, 20 second timeout, 1 retry, suspended in low power mode, and restricted on a metered network to small payloads.
• Block 2: nothing is persisted. A prefetch that is lost to a process kill is simply not done, and re-deriving it on relaunch is cheaper than storing it.
• Block 3: retries are capped at 1 because a prefetch that fails is worth less than the radio time a second attempt costs. The deadline is the moment the user scrolls past the item, at which point the request is cancelled.
• Block 4: you handle deduplication and cancellation.

Faded example 2. The operation is submitting a payment. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: the user is watching a spinner and will not leave the screen, so this is user blocking. Concurrency is irrelevant (there is one), timeout is 10 seconds per attempt.
• Block 2: persist first. The payment intent, its idempotency key and its state go into durable storage before the request is issued, because the user may force quit at exactly the wrong moment and the app must be able to ask the server what happened.

6f. Check yourself

Q1. Your client has 50,000 active devices. A backend deploy causes 90 seconds of 503 responses. With the 6a configuration (5 retries, backoff 1, 2, 4, 8, 16, no jitter, no budget), estimate the load pattern the recovering servers see. Then estimate it with full jitter and a 10 percent retry budget.

Q2. A screen makes 5 calls to render. Using the round trip arithmetic in 6b, quantify the cost of making them sequentially on fresh connections against making them concurrently on one reused connection, at 150 milliseconds round trip time and 100 milliseconds of server time each. Then say which module 5 decision this argues for.

6g. When not to use this

The full pipeline (tiers, dedupe, budgets, deadlines) is the right default for a consumer app at scale, and it is genuinely too much for some clients.

Module 7. Pagination done properly

Time: 25 to 35 minutes reading, 15 to 25 minutes practice.

7a. Predict first

A client paginates a feed with offset and limit. One item is inserted at the head between the two requests.

t0   server list       A B C D E F G H
     client requests   limit 4  offset 0
     client receives   A B C D

t1   item Z is inserted at the head
     server list       Z A B C D E F G H

t2   client requests   limit 4  offset 4
     client receives   D E F G

Figure an offset paginated list with one insertion between two pages

7b. The four schemes, compared on the things that actually differ

Terms first.

The deep page cost, derived. A database asked for offset 100,000 with limit 20 must produce and discard 100,000 rows before returning 20. It reads roughly 100,020 index entries. The keyset form, "where sort key is less than the last value I saw", seeks directly and reads 20. That is about a 5,000 times difference in work, and it grows without bound as the user scrolls.

Keyset needs a unique sort key, and here is why. Sort by a timestamp with second granularity and three items share a timestamp. The page boundary lands in the middle of that group. The next request asks for items strictly before that timestamp, so the other two items in the group are skipped. Ask for items at or before it, and the item you already have is duplicated.

The fix is a compound key: sort by (timestamp, identifier) and compare the pair. The identifier breaks every tie, so the ordering is total and the boundary is exact.

Cursor is not an alternative to keyset, it is a wrapper around it. A cursor is usually a keyset position with a signature and a version stamp, encoded so the client cannot read it. That opacity is the whole benefit: the server can switch from a timestamp key to a score key, or add a snapshot identifier, without a client release. From module 2, that is worth 30 days.

The four failure modes, named

The fourth is the subtle one and it is common. Two rules prevent it.

1. End of list is a server assertion, not a client inference. The server returns an explicit "no more" signal, and the client never concludes the end from a short or empty page.
2. If a page deduplicates to zero items, the client requests the next page automatically rather than stopping, with a small cap on consecutive empty pages so a broken cursor cannot loop.

Ranked feeds, where even keyset is not enough

A ranked feed recomputes scores per request, so the sort key itself changes between page one and page two. Keyset on a moving score is unstable by construction.

The fix is a ranking session: the server materialises an ordered list of identifiers once, stores it, and paginates within it. The cursor becomes (session identifier, position).

Cost it, so that the answer is a design rather than a wish. Assume 10 million daily active users, 3 sessions each per day, a materialised list of 500 identifiers, 8 bytes per identifier, and a 30 minute session lifetime.

• Bytes per session: 500 times 8 equals 4 kilobytes.
• Sessions per day: 10 million times 3 equals 30 million.
• Concurrently live sessions: a day holds 48 half hour windows, so about 30 million divided by 48, which is 625,000.
• Memory at any instant: 625,000 times 4 kilobytes equals about 2.5 gigabytes.

Two and a half gigabytes in a cache tier is unremarkable, so the design is affordable, and now you can defend it with arithmetic rather than with confidence. If the number had come out at 2.5 terabytes, the correct answer would be to materialise only the first 100 identifiers and re-rank beyond that, accepting instability deep in the feed where almost nobody scrolls.

7c. The client half, which is where most of the bugs live

The server can be perfect and the list can still be wrong. Five client rules.

CACHED       A B C D E F
REFRESH      Z Y A B
overlap at A so prepend Z Y and keep scroll anchored on D

CACHED       A B C D E F
REFRESH      Q R S T
no overlap so there is a hole between T and A

+-------------------------------+
| Q R S T                       |
| = = = gap  tap to load = = =  |
| A B C D E F                   |
+-------------------------------+

Figure refresh merged with overlap and refresh that reveals a hole

7d. Worked example: pagination for a ranked feed with pull to refresh

The prompt: an infinite feed, ranked server side, with pull to refresh and occasional real time insertions at the head.

Block 1. PURPOSE: choose the scheme from the ordering property, not from habit.

I ask one question: is the ordering stable between requests? The answer is no, because ranking is recomputed. That single fact eliminates offset, page number and plain keyset in one move, and it leaves cursor plus a ranking session.

I say the elimination out loud, because eliminating three options with one question is exactly what the estimation discipline is for.

The error most readers make here is reaching for cursor pagination because it is the known good answer, without noticing that a cursor over an unstable ordering is still unstable. The cursor is necessary and it is not sufficient.

Block 2. PURPOSE: design the cursor so the server keeps its freedom.

The cursor is an opaque string. Inside it, and invisible to the client, the server puts the ranking session identifier, the position in the materialised list, and a schema version.

The expiry needs a defined behaviour, not just a rejection. On an expired cursor the server starts a fresh session and returns a flag telling the client this is a discontinuity, so the client can clear rather than append.

Block 3. PURPOSE: define refresh separately from append, because they are not the same request.

That last row is a product decision with a technical cause. Inserting content above the reading position while the user is reading moves what they are looking at, so the correct behaviour is to hold the new items and offer them.

The error most readers make here is one endpoint with one merge rule for both refresh and append. The list then either loses scroll position on every refresh or accumulates duplicates on every insertion.

Block 4. PURPOSE: state the client rules that make the correct server behaviour survive contact with a real device.

Four commitments, all from 7c: deduplicate on merge, anchor the scroll to an item identifier, persist the cursor with the cached page so a process kill resumes rather than restarts, and never infer the end of the list from an empty page.

I add one measurement so the design is checkable in production: count duplicate identifiers observed per session and the rate of gap markers shown. Both should be near zero, and a rise in either is a pagination regression that no crash reporter will ever tell you about.

The error most readers make here is shipping pagination with no telemetry. Duplicates and skips are silent, users rarely report them, and without a counter you hear about them from a screenshot on social media.

Result. One question eliminated three schemes, the cursor is opaque so the server keeps its freedom, refresh and append are different operations with different merge rules, and two counters make the whole thing observable.

7e. Fade the scaffold

Faded example 1. The prompt is paginating chat message history, scrolling upward into the past, while new messages arrive at the bottom. Blocks 1 to 3 are given. Produce block 4.

• Block 1: the ordering is stable, because messages are ordered by a server assigned sequence number that never changes. That admits plain keyset and there is no need for a ranking session.
• Block 2: the cursor is a keyset position over (sequence number), which is already unique, so no tie breaker is needed. Pagination is bidirectional: give me 50 before sequence X for history, give me everything after sequence Y for new messages.
• Block 3: history load and live tail are different operations. History appends upward and never touches the tail. The live tail appends downward and never touches history.
• Block 4: you state the client rules and the telemetry.

Faded example 2. The prompt is paginating search results where the user can change the sort order mid scroll. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: ordering is stable for a fixed query and sort, but a sort change is a different ordering entirely, so it is a new list rather than a continuation.
• Block 2: the cursor encodes the query, the sort, a result set identifier and a position, and it expires. Any change to query or sort invalidates the cursor by construction, because they are inside it.

7f. Check yourself

Q1. A feed serves 20 items per page with offset pagination. Measurement shows an average of 2 insertions above the read position per page request. A user scrolls 10 pages. Estimate how many duplicates they see, and say why the equivalent skip count is more damaging even when it is smaller.

Q2. Your cursor currently encodes a plain timestamp of the last item. An engineer proposes adding a secondary sort by popularity for a new surface. What breaks, and what is the minimal change?

7g. When not to use this

Cursor pagination with ranking sessions is correct for a large mutating feed and is genuine over-engineering for many lists.

Module 8. Media in: the image pipeline

Time: 35 to 45 minutes reading, 20 to 30 minutes practice.

8a. Predict first

Here is how a list row loads its image, and what the user does.

row binds
    imageView load  url
    url points at the 4000 by 3000 original
    no target size passed
    no cancellation when the row is recycled
    memory cache    none
    disk cache      none

user flings the list past 60 rows in 3 seconds

Figure a naive image load in a recycling list during a fast scroll

8b. The pipeline, stage by stage

Terms first.

The stages, in order, with the decision that lives at each.

The cache key is the design. The key must contain the source identifier, the target dimensions in pixels, and a stable description of the transform chain.

• Key on the URL alone and a 96 pixel avatar shares an entry with a 1080 pixel full screen render. One of them is wrong, and which one depends on scroll order.
• Include the transforms and a rounded thumbnail no longer collides with a square one.
• Two caches, two key shapes: the disk cache holds encoded bytes keyed by the source URL, because the bytes are the same whatever you will do with them. The memory cache holds decoded bitmaps keyed by source plus size plus transforms.

Downsampling, with the arithmetic

A 4000 by 3000 source, needed at 540 by 540 physical pixels for a feed card.

The sample factor is chosen as the largest power of two that still leaves both dimensions at or above the target. Here 4000 divided by 540 is 7.4 and 3000 divided by 540 is 5.6, so the largest safe power of two is 4, giving 1000 by 750, both still above 540.

Never pick a factor that takes a dimension below the target, because upscaling a too-small bitmap is visible immediately and is the most common downsampling bug.

Pixel format. Four bytes per pixel gives 8 bits each of red, green, blue and alpha. Two bytes per pixel drops alpha and reduces colour precision, halving memory. It is a real option for opaque photographic thumbnails and a bad one for gradients or anything with transparency, where banding is obvious. State the trade rather than defaulting silently.

Sizing the three tiers, from the module 3 budget

What 24 megabytes of memory cache actually holds. At 1.17 megabytes per feed bitmap, 24 divided by 1.17 is about 20 bitmaps. With 8 cards visible per screen, that is 2.5 screens of scroll history, which is enough that a short scroll back is instant and a long one is not. That is the correct trade: instant scroll back is a nice-to-have, and termination from footprint is not.

What 150 megabytes of disk cache actually holds. At the module 3 figure of about 50 kilobytes per 540 by 540 encoded image, 150 megabytes holds about 3,000 images. Assume a user views 5 screens per session at 8 images per screen, 3 sessions a day, so 120 images a day. That is 25 days of history, far more than anyone scrolls back through, so the size is generous and could be halved without a measurable hit rate change.

Two disk cache rules that are not about size. First, store it in a location the operating system is allowed to purge, because a cache that the system cannot reclaim under storage pressure becomes the user's reason to delete your app. Second, write through a journal, so a process killed mid write leaves a recoverable cache rather than a corrupt entry.

Eviction, and the rule that prevents a crash

Also respond to the system memory warning: drop the memory cache to a small fraction rather than clearing it entirely, because clearing it guarantees a full reload storm the moment the user scrolls.

Placeholders and prefetch, both derived

Placeholders. Embed a tiny preview in the list response itself, so a card is never blank. At 32 by 32 pixels the encoded preview is on the order of a kilobyte.

• 8 cards times 1 kilobyte equals 8 kilobytes added to a 50 kilobyte page response, about 16 percent larger.
• In exchange, first paint has real colour and shape in every card at the moment the list appears, with zero extra requests.

That is one of the best trades available on a feed, and the arithmetic is what makes it defensible rather than a matter of taste.

Prefetch distance, derived. Assume a fast scroll of 2,000 pixels per second and a card height of 400 pixels, so the user passes 5 cards per second. Assume fetch plus decode takes 300 milliseconds, during which the user passes 1.5 cards.

• Minimum useful prefetch distance: 2 cards.
• Add margin for latency variance: 4 cards ahead.
• Speculative cost if the user stops immediately: 4 times 50 kilobytes equals 200 kilobytes wasted, which is acceptable on an unmetered network and worth capping to 2 cards on a metered one.

Prefetch runs in the opportunistic tier from module 6, so it never competes with a request the user is waiting for.

8c. The pipeline as a picture

key = source id + target pixel size + transform chain
        |
        v
+---------------------------------------------------+
| MEMORY CACHE   24 MB   LRU by bytes   hit=deliver  |
+---------------------------------------------------+
        | miss
        v
+---------------------------------------------------+
| DISK CACHE   150 MB   encoded bytes   hit=decode   |
+---------------------------------------------------+
        | miss
        v
+---------------------------------------------------+
| NETWORK   opportunistic tier   coalesce same key   |
+---------------------------------------------------+
        |
        v
+---------------------------------------------------+
| DECODE and DOWNSAMPLE then TRANSFORM then cache    |
+---------------------------------------------------+
        |
        v
+---------------------------------------------------+
| DELIVER only if the target still wants this key    |
+---------------------------------------------------+

Figure the three tier image path with delivery guarded by the key

8d. Worked example: the image path for one feed card

The prompt: a feed of cards, each with one photo, on the mid tier device from module 3.

Block 1. PURPOSE: write the cache key first, because every later decision depends on it.

The key is source identifier plus target pixel size plus an ordered transform description. Concretely, a card image at 540 by 540 with a rounded corner transform is a different entry from the same photo at 96 by 96 for the author avatar.

I say why out loud: the memory cache stores decoded bitmaps, and a decoded bitmap has exactly one size, so a key that omits the size describes something that does not exist.

The error most readers make here is keying on the URL because that is what the disk cache does. The two tiers store different things and therefore need different keys, and conflating them means either wrong sized images or a memory cache that never hits.

Block 2. PURPOSE: size the tiers from the budget I already committed to, not from a default.

From module 3 I own 24 megabytes of image memory on a 192 megabyte heap. From 8b that is about 20 bitmaps at 1.17 megabytes each, which is 2.5 screens.

I state the consequence I am accepting: scrolling back more than about two screens will re-decode from the disk cache, which costs roughly the decode time rather than a network round trip. That is a deliberate trade of scroll-back smoothness against termination risk, and termination is worse (module 3 priced it at a 7.5 times penalty).

The error most readers make here is sizing the memory cache as a fraction of available memory measured at runtime. Available memory is high right after launch and low later, so the cache grows into exactly the memory the system was about to want back.

Block 3. PURPOSE: keep the decode off the frame budget.

Module 3 gives 6.2 milliseconds of application work per frame at 120 hertz. A decode of a 1000 by 750 intermediate is far longer than that, so the decode happens on a background thread, always, with no exception for cache hits from disk.

Two consequences I state:

• The bind path must be synchronous and cheap: set the placeholder, start the request, return. A synchronous disk read during bind is enough to drop frames on its own.
• The memory cache lookup may happen on the main thread, because it is a hash lookup of tens of microseconds, and making it asynchronous would cause a visible flash of placeholder on an image that was already in memory.

That second point is a real distinction and it is worth making: the fast path is synchronous, everything else is not.

Block 4. PURPOSE: make cancellation and prefetch behave like one system.

Every request carries the target's generation token. When a row is recycled the token changes, which does three things: the in-flight request is cancelled if it is not nearly complete, any arriving result is discarded rather than delivered, and the slot is freed for the newly bound row.

Prefetch uses the derived window from 8b: 4 cards ahead in the scroll direction, opportunistic tier, cut to 2 on a metered connection, suspended entirely in low power mode. When a prefetched request is still in flight and the row becomes visible, it is promoted to the user blocking tier rather than re-issued, which is the promotion rule from module 6.

The error most readers make here is cancelling only the callback and not the transfer. The bytes still arrive, so the radio time is spent and the battery cost of a fling through 60 rows is unchanged. Cancellation must reach the transport to be worth anything.

Result. The key is defined before the caches, the tiers are sized from a budget set two modules earlier, the decode never touches the frame budget, and cancellation and prefetch are the same mechanism seen from two directions.

8e. Fade the scaffold

Faded example 1. The surface is a full screen photo viewer with pinch to zoom, opened from the feed. Blocks 1 to 3 are given. Produce block 4.

• Block 1: the key now includes a zoom tier, because a zoomed region needs a different decode than the fitted view. Tiers are fit-to-screen, 2 times and 4 times.
• Block 2: memory sizing changes. One fitted full screen bitmap at 1080 by 2400 is 10.4 megabytes (module 3), so the 24 megabyte budget holds two of them plus nothing else. The viewer therefore gets its own smaller cache holding the current image and its immediate neighbours, and the feed's cache is left alone.
• Block 3: decode stays off the main thread, and the fitted image is shown first while a higher tier decodes in the background.
• Block 4: you design cancellation and prefetch for the swipe between photos.

Faded example 2. The surface is a chat list showing 40 small avatars, many of them repeated because the same people appear in several conversations. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: key is source plus 96 by 96 pixels plus a circular crop transform. Small and uniform.
• Block 2: sizing is different in kind. At 96 by 96 and 4 bytes per pixel, one avatar is 96 times 96 times 4 equals 36,864 bytes, about 36 kilobytes. A 4 megabyte avatar cache holds about 110 avatars, which is more distinct people than a chat list shows, so the entire working set fits in memory.

8f. Check yourself

Q1. Your feed shows 8 cards per screen and users report the app being killed in the background. Memory profiling shows 24 megabytes in the image cache and 90 megabytes in bitmaps that are not in the cache. Explain what is most likely happening and give the fix.

Q2. A teammate proposes caching decoded bitmaps on disk to avoid re-decoding. Evaluate it with numbers from this module.

8g. When not to use this

Almost nobody should write this pipeline from scratch, and saying so is a strong answer rather than a weak one.

Module 9. Media out: uploads that survive the real world

Time: 30 to 40 minutes reading, 20 to 25 minutes practice.

9a. Predict first

Here is how an app uploads a photo, and the network it runs on.

user picks a 4 MB photo and taps send
app holds the bytes in memory
app posts the whole file in one request
app drives progress from bytes written to the socket
app retries the whole request twice on failure
app cancels the upload if the user leaves the screen

uplink is 1 megabit per second
the link drops for about 5 seconds twice a minute

Figure a single shot upload on a link that drops twice a minute

9b. Resumable chunked upload, and how to size the chunk

A resumable upload is a three phase protocol. Each phase exists for a reason worth naming.

The rule that makes the whole thing work. The server's committed offset is the truth, and the client's recorded offset is a hint. A process can die after the bytes were sent and before the client wrote down that it sent them, so the client must always ask before resuming.

Chunk size, derived rather than chosen

Two forces pull in opposite directions.

Price both on the 9a network (1 megabit per second, 1 drop per 30 seconds) with a 150 millisecond round trip.

Expected total bytes sent, which is the number that decides it. With resumability only the failed chunk is resent, so expected bytes are roughly the file size divided by the per chunk success probability.

• Single shot: 4 divided by 0.34 equals 11.8 megabytes.
• 1 megabyte chunks: 4 divided by 0.76 equals 5.3 megabytes.
• 256 kilobyte chunks: 4 divided by 0.94 equals 4.3 megabytes, but with 7.5 percent overhead added back.

The rule to carry. Choose a chunk that takes roughly 5 to 10 seconds to transfer at the measured uplink, clamped to a sensible range such as 256 kilobytes to 8 megabytes. Measure throughput during the upload and resize the next chunk. That single adaptive rule beats any fixed constant, because the same app runs on a 100 megabit per second home connection and a 0.3 megabit per second rural cellular link.

The durable queue, because memory is not a place to keep a user's photo

One row per upload, in the local database, written before any bytes move.

The state machine, with terminal states that are honest about the different ways an upload ends.

+--------+     +-----------+     +-----------+     +----------+
| QUEUED |====>| PREPARING |====>| UPLOADING |====>| FINISHED |
+--------+     | compress  |     | chunks    |     +----------+
                +-----------+     +-----------+
                                    |  |  |
              +---------------------+  |  +-------------------+
              v                        v                      v
        +-----------+           +-------------+        +-------------+
        | UNAVAIL   |           | EXPIRED     |        | FAILED      |
        | source is |           | past the    |        | server said |
        | gone      |           | horizon     |        | no          |
        +-----------+           +-------------+        +-------------+

Figure the upload state machine with three distinct terminal failures

Three terminal failures rather than one, because they need different interfaces: source gone means offer to pick again, expired means offer to retry manually, and rejected means show the server's reason.

9c. Process death, compression and honest progress

Surviving process death and backgrounding

Two mechanisms, used at different times.

The background service imposes real constraints that are worth naming in a round: the payload usually has to be a file on disk rather than a stream you generate, you get no arbitrary code during the transfer, and the operating system decides when it runs. So the handoff has to write the current chunk to a file and record enough state that a relaunched process can pick up the result.

Reconciliation on launch, which is the piece most designs forget. For every non-terminal row: ask the server for the session's committed offset, compare it to the local hint, and continue. Do not assume the local hint is right and do not assume it is wrong.

Client side compression, decided by arithmetic

A 12 megapixel photo, 4000 by 3000, roughly 3.5 megabytes as captured.

Spend 400 milliseconds of processor time to save about 24 seconds of radio time. From module 3, sustained radio use is one of the dominant battery terms, so this is a win on time, on data allowance and on battery at once. It is close to the clearest trade in this whole course.

When not to compress, which matters just as much.

A workable rule: compress when the predicted output is under about 60 percent of the input and the product does not promise originals. Predict from the pixel arithmetic above rather than by encoding and checking, so you do not pay the processor cost to discover it was not worth paying.

Video, where the arithmetic is more dramatic. A 60 second clip captured at 4K and roughly 50 megabits per second is 60 times 50 divided by 8, which is 375 megabytes. At 1 megabit per second that is 3,000 seconds, about 50 minutes.

Transcoded to 1080p at 8 megabits per second it is 60 megabytes, about 8 minutes of transfer, against perhaps 30 to 60 seconds of on device encoding. The transcode is obviously correct. The honest caveat is that on device encoding is heavy enough to be worth deferring until the device is charging if the upload is not urgent.

Progress that does not lie

Drive progress from the committed offset the server acknowledged, not from bytes written to the socket. Bytes written include bytes buffered in the operating system that may never arrive, which is why a naive progress bar reaches 100 percent and then restarts.

Report progress as the maximum committed offset ever observed, so it is monotone. A progress bar that goes backwards is read as a bug even when the underlying behaviour is correct.

9d. Worked example: uploading a photo attached to a post

The prompt: the user picks a photo, writes a caption, and taps post. The post must appear immediately in their own feed.

Block 1. PURPOSE: decide compression before anything else, because it changes every number downstream.

The photo is 3.5 megabytes at 4000 by 3000, and the product does not promise originals. Using the compression arithmetic in 9c, resizing to a 2048 pixel long edge yields about 535 kilobytes for about 400 milliseconds of processor time, turning a 28 second transfer into a 4.3 second one.

I decide to compress, and I state the consequence for chunking: a 535 kilobyte payload at 1 megabit per second is about 4.3 seconds of transfer, which is already inside the 5 to 10 second target band, so this upload is a single chunk and the chunking machinery only engages for larger media.

The error most readers make here is designing the chunking protocol first and then discovering that the typical payload fits in one chunk. Compress first, then size the chunks against what is actually being sent.

Block 2. PURPOSE: make the post durable before the user's attention moves on.

Order, and it is the same order as module 6's like tap for the same reason.

1. Write the post row locally: caption, local asset reference, idempotency key, state Queued.
2. Insert the post into the local feed immediately, marked pending, so it appears in the user's own feed.
3. Dismiss the composer.
4. Only now start preparing and uploading.

The user's post exists from step 1 onward, whatever happens to the process, the network or the app.

The error most readers make here is keeping the composer on screen until the upload finishes. That converts a background operation into a modal wait, and it is why users think uploads are slow when the actual constraint is that they were prevented from doing anything else.

Block 3. PURPOSE: define what happens at each of the four ways this can go wrong.

Note the deliberate asymmetry: two of these are invisible to the user by design, and two must be visible immediately. Deciding which failures deserve the user's attention is a design decision, not an implementation detail.

Block 4. PURPOSE: set the expiry horizon and the progress rule, so the queue cannot rot.

Expiry: 7 days. After that, an unposted post is more likely to confuse than to please, and the session on the server has probably expired anyway. On expiry the row moves to Expired, the local post is removed from the feed with a notice, and the event is counted.

Progress: driven by the committed offset, monotone, and reported at most a few times a second so that progress updates do not themselves cost frames (module 3's budget is 6.2 milliseconds and a progress update that triggers a layout pass is not free).

The error most readers make here is an unbounded queue. Rows accumulate for months, the reconciliation on launch grows linearly, and cold start regresses for a reason nobody can find. Every durable queue needs a horizon.

Result. Compression decided by arithmetic, durability before transmission, four failure paths with two of them deliberately invisible, and a bounded queue with honest progress.

9e. Fade the scaffold

Faded example 1. The prompt is uploading a 200 megabyte video from the share sheet. Blocks 1 to 3 are given. Produce block 4.

• Block 1: transcode on device, using the 9c arithmetic. 200 megabytes at 1 megabit per second is 1,600 seconds, about 27 minutes. Transcoding to a lower bitrate brings it to roughly 35 megabytes and about 5 minutes of transfer, for perhaps 40 seconds of encoding.
• Block 2: durable first. The row exists before the transcode starts, because a transcode is long enough that the process can die during it.
• Block 3: chunking now matters. At 35 megabytes and a target of 5 to 10 seconds per chunk on a 1 megabit per second link, chunks are about 1 megabyte, so roughly 35 chunks, resized adaptively as measured throughput changes.
• Block 4: you handle backgrounding, expiry and progress.

Faded example 2. The prompt is uploading crash reports and diagnostic logs. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: compress aggressively, because logs are text and compress by roughly an order of magnitude, and nobody needs the original bytes.
• Block 2: durable, but with a different urgency. The crash report must be written to disk from inside a crashing process, so it is written by a minimal handler with no allocation, and uploaded on the next launch rather than the current one.

9f. Check yourself

Q1. Your uploads use 8 megabyte chunks. Field telemetry shows a median uplink of 0.8 megabits per second and a connection interruption roughly every 45 seconds. Compute what is happening and give the new chunk size.

Q2. A colleague says resumable upload is unnecessary because the network layer already retries. Give the specific case that defeats retry, and the smallest addition that fixes it.

9g. When not to use this

Full resumable upload with a durable queue is correct for user generated media and is too much for many payloads.

Module 10. Push and real-time delivery

Time: 30 to 40 minutes reading, 15 to 25 minutes practice.

10a. Predict first

Here is the push design of a messaging app.

server sends one push per chat message
payload carries   sender name  message text  thread id  unread count
priority          high  for every message
collapse key      none
time to live      28 days
token store       tokens are inserted  never removed
silent push       one per message  to sync state in the background

Figure a push design with six independent defects

10b. What push actually guarantees, which is almost nothing

Push is a best effort hint delivery service operated by the platform. Write the guarantees down honestly, because every design error in this area comes from assuming one it does not have.

The consequence, and it is the single most useful sentence in this module. Push is a hint, not a transport. The pattern that follows is notify then fetch: the payload carries an event type and the minimum identifier needed to act, and the client fetches authoritative state from your own API.

Price it, because the extra request looks like a cost until you count properly.

The third row costs one request and buys correct counts, correct ordering, full message text, and no user content sitting on a service you do not run.

+--------+  event  +---------+  hint   +--------+  fetch  +-----+
| SERVER |========>| PUSH    |========>| CLIENT |========>| API |
| writes |         | SERVICE |         | wakes  |<========|     |
| message|         | best    |         | and    |  truth  +-----+
+--------+         | effort  |         | fetches|
                   +---------+         +--------+
                                            |
                                            v
                                    +----------------+
                                    | LOCAL STORE    |
                                    | is the truth   |
                                    | shown to user  |
                                    +----------------+

Figure notify then fetch with the local store as the displayed truth

10c. Tokens, priority, collapse and time to live

Token lifecycle

A push token identifies an app installation on a device for the push service. It is not a user identifier and it is not stable.

The registration record, and the one design rule. Key the server record by installation identifier, not by token. A token rotation then updates a row rather than inserting one. Key by token and every rotation creates a duplicate row, so a single device accumulates entries and receives the same notification several times.

A workable record: installation identifier, user identifier, current token, platform, app version, declared capabilities (module 5), last successful delivery, last app open.

Dead token reaping, with the arithmetic

Assume 10 million installs and that 1.5 percent of installations per month produce a token invalidation through reinstall, restore, data clearing or permission revocation.

• Dead tokens per month: 10,000,000 times 0.015 equals 150,000.
• After 24 months with no reaping: 150,000 times 24 equals 3.6 million dead rows.
• As a fraction of the live base: 3.6 million against 10 million live, so about 26 percent of every fan-out is wasted.
• At one notification per user per day, that is 3.6 million wasted sends per day, plus the latency cost of a fan-out that is a quarter larger than it needs to be.

Two reaping mechanisms, both needed.

1. Synchronous. The push service reports per token that a token is unregistered or invalid. Delete or tombstone that row in the same operation that sent the batch. This catches the majority and costs nothing extra.
2. Time based sweep. No successful delivery and no app open for 90 days, so mark the installation dormant and stop sending. Keep the row for analytics rather than deleting it, so you can measure how large the dormant population is.

Why 90 days for the sweep: it is long enough that a normal user on holiday or on a second device is not reaped, and short enough that the dormant set does not dominate the fan-out. It is a policy choice, so state it as one and say what you would measure to tune it, namely the rate at which reaped installations later return.

Priority

The rule. High priority requires a user visible notification that a reasonable user would call urgent. Using high priority to drive a silent background sync is the classic abuse, and the penalty is that the platform throttles your app, which removes the mechanism you were relying on.

Collapse key and time to live

A collapse key tells the service that only the most recent undelivered message with that key needs to be delivered. A time to live tells it how long to hold an undelivered message before dropping it.

Collapse key granularity is a product decision. Use the level the user perceives.

Keep the number of distinct collapse keys modest, because services impose limits on how many pending keys they will track per device, and exceeding the limit degrades in ways you cannot observe from the client.

Time to live, chosen by a single question: after how long would delivering this message be a bug?

Silent push, and the rule that makes it safe

A silent push wakes the app briefly with no user visible notification. Platforms budget and throttle these: the number per app per period is capped, and an app that receives them and does nothing useful, or whose user rarely opens it, gets throttled further.

The design rule that makes silent push safe to use. Every silent push must be redundant. The app must reach exactly the same state on its next foreground without it. If missing a silent push causes a correctness bug, the design is wrong, because the platform is entitled to drop every one of them.

Good uses, all of which satisfy that rule: warm a cache so the app opens fresh, invalidate a cache entry, and trigger an outbox flush that would have happened on foreground anyway.

Badge and count consistency

Counts must be sent as absolute values computed by the server, never as increments.

Derive why. Assume 5 percent of pushes are not delivered.

• With increments, after 100 events the expected error is 5 events, and the error is permanent because there is nothing to correct it against. Errors accumulate over weeks.
• With absolute values, the error is bounded by the staleness of the last delivered push, and the next successful delivery corrects it completely.

Even absolute values are stale at delivery, so the authoritative count comes from your own sync response on foreground. The badge is a best effort approximation that self corrects, which is the most that push semantics allow.

The transport decision, in one table

The combination that is almost always right on a phone: platform push when backgrounded, a live connection only while in the foreground, and a reconciling fetch on every foreground transition regardless of what arrived.

10d. Worked example: delivery for a chat client

The prompt: messages must feel instant when the app is open, must arrive when it is closed, and counts must be right across three devices.

Block 1. PURPOSE: decide what the push carries, because that decision constrains everything else.

Notify then fetch. The payload carries the event type, the conversation identifier, a monotonically increasing server sequence number, and a short localised preview string produced by the server for the notification text only.

Why a preview string rather than the message text: the notification must be readable before the fetch completes, so something has to be displayable immediately. Making it a server produced display string rather than the raw content means it can be truncated, localised and redacted according to the user's own lock screen preference, which the server knows and the payload does not have room to reason about.

The error most readers make here is either putting the whole message in the payload (which fails on size, privacy and staleness) or putting nothing in it (which means a notification cannot be shown until a network fetch succeeds, and that fetch may fail).

Block 2. PURPOSE: get the token lifecycle right, since it is the part that silently rots.

Register by installation identifier, not by token. Update on every rotation callback and on every app launch, because a launch is a free opportunity to correct drift.

Reap on both mechanisms from 10c: synchronously on an invalid token result, and by a 90 day dormancy sweep. Using the 10c arithmetic, doing neither would leave about 26 percent of the fan-out wasted within two years.

Multi device: the fan-out targets every live installation for the user, so the send path is a query over installations, not a single token lookup. That is exactly why keying by installation matters.

The error most readers make here is treating the token as the user's address. A user has several devices, each device's token changes over time, and a token that worked yesterday can be invalid today.

Block 3. PURPOSE: set priority, collapse and time to live per message class rather than globally.

The typing indicator row is the interesting one. It belongs to the foreground connection only, because a typing indicator delivered by push is both useless (it will arrive after the typing stopped) and expensive (it would wake the device for nothing).

Block 4. PURPOSE: make counts correct across three devices, given that push guarantees nothing.

Three rules, and the third is the one that makes it actually work.

1. The badge value is an absolute count computed by the server at send time.
2. On every foreground transition the client fetches the authoritative unread state and overwrites the badge, whatever push said.
3. Read state is a synchronised value, not a local one. Reading on the phone must clear the count on the tablet, so the read receipt is a write that goes through the same outbox as a message (module 6), and other devices discover it through the same notify then fetch path.

Silent push carries the read state change to the other devices, and by the 10c rule it is redundant: if the silent push is dropped, the other device corrects itself on its next foreground.

The error most readers make here is treating read state as a local user interface concern. It is shared state across devices, and it is the single most visible correctness bug in multi device messaging.

Result. The push carries a hint plus just enough to render a notification, tokens are keyed and reaped so the fan-out stays honest, delivery parameters vary by message class, and counts converge through a fetch rather than depending on delivery.

10e. Fade the scaffold

Faded example 1. The prompt is order status for a food delivery app: confirmed, being prepared, on the way, arriving now, delivered. Blocks 1 to 3 are given. Produce block 4.

• Block 1: notify then fetch, with the payload carrying the order identifier, the new status, and a status timestamp. The status is included because the notification text depends on it and must render offline.
• Block 2: token lifecycle as in 10d, with one addition: an order is short lived, so a failed delivery during an active order is worth escalating to a fallback channel rather than merely retrying.
• Block 3: priority is high for arriving now and delivered, normal for confirmed and being prepared. Collapse key is the order identifier for all of them. Time to live is 5 minutes for arriving now, 1 hour for the rest.
• Block 4: you handle out of order delivery and the interface consequence.

Faded example 2. The prompt is a breaking news alert sent to 20 million devices at once. Blocks 1 and 2 are given. Produce blocks 3 and 4.

• Block 1: the content is public, short, and identical for everyone, so this is the one case where putting the headline in the payload is correct rather than lazy.
• Block 2: tokens as before, and the dormancy sweep matters much more here, since a 26 percent wasted fan-out on a 20 million device send is over 5 million pointless deliveries per alert.

10f. Check yourself

Q1. Your app has 5 million installs and no dead token reaping after 18 months, with an invalidation rate of 1.5 percent of installs per month. Quantify the waste, then say which of the two reaping mechanisms you would ship first and why.

Q2. A colleague proposes using a silent push after every server side data change to keep the client's cache warm, at roughly 40 per user per day. Evaluate it.

10g. When not to use this

Push is cheap to add and expensive to get right, and there are cases where the right answer is less of it.

Module 11. The sync engine

Time: 45 to 60 minutes reading, 20 to 30 minutes practice.

Every other subsystem on this page degrades when it fails. A slow image is slow, a dropped push is late, a missed frame is ugly. Sync is the one that destroys work the user typed, silently, with nothing in your telemetry to show for it. This module builds a sync engine in the order you would draw it in a round, and prices each mechanism before adding it.

11a. Predict first

Here is the sync design of a notes app that runs on a phone and a tablet.

local write        update the note row  then POST it
send queue         in memory list  drained by a background task
conflict rule      last write wins  by the device clock field
delete             remove the row locally  then DELETE on the server
pull               GET /notes  the whole list  on every foreground
after a kill       queue rebuilt by scanning rows marked dirty

Figure a sync design with six independent defects

11b. Two shapes of sync, and the count that chooses between them

There are two honest answers to "how does a change travel", and picking the wrong one costs a month.

The count that chooses. How many writers can touch the same object inside the same second?

• One writer on several devices. Use state sync with a per-field rule table. Simultaneous edits are rare, and when one is lost the same person can see it and retype it.
• Several writers on the same object at once. Use an operation log or a CRDT, because "the loser retypes" stops being acceptable the moment the loser is a different person.

Say that count out loud in a round. "One writer, several devices" is the sentence that lets you skip a month of design without sounding as though you skipped it.

11c. Five mechanisms, each priced before it is added

Mechanism 1. The write-ahead pattern, which is one transaction and two rows

The local row and the outbox row commit together, and the interface says saved only after that commit returns.

The rule. The word "saved" in the interface is a claim about durability, so it may only appear after the transaction that contains both rows has committed. Anything else is a claim you cannot keep.

The idempotency key is generated at enqueue, not at send, for the reason module 6 gives: a key generated per attempt turns every retry into a new object.

Mechanism 2. Delta sync and the change token

A change token is an opaque server cursor over the change stream for one account. It is a position, and the server owns it. The client stores it and never interprets it.

Three reasons the token is not a timestamp: two writes can land in the same millisecond, server nodes disagree about the current millisecond, and a timestamp cannot express "you are too far behind to catch up incrementally".

Price it. Assume 400 notes at an assumed 5 KB each, which is a plausible average for a text note with light formatting. Measure your own median and 90^th percentile rather than adopting this one.

• Full pull: 400 times 5 KB equals 2,000 KB, about 2 MB.
• Steady state: assume 4 notes change between one foreground and the next, and that the changed fields on a note average 200 bytes.
• Delta body: 4 times 200 equals 800 bytes. Plus an assumed 120 bytes of envelope and new token, so about 920 bytes.
• Ratio: 2,000,000 divided by 920 is about 2,170 times.
• At 6 foregrounds a day: the full pull is 12 MB a day and about 360 MB a month per user. The delta is 5,520 bytes a day, about 166 KB a month.

That is the number that eliminates the full pull, and it eliminates it on the user's data plan rather than on your server bill, which is the version of the argument that wins the room.

Mechanism 3. Tombstones, and the horizon they force

A delete has to travel as a value. An absence cannot travel, because a delta response contains only what changed, and "not present" is indistinguishable from "not changed".

A tombstone row is small: entity identifier, entity type, and the version at which it was deleted. No payload, because the payload is what you are deleting.

Price the retention. The product promise is 30 days offline, so retention is 35 days, with the extra 5 days as margin for a device that returns late.

• Assume 2 deletions a day for an active user, so about 70 tombstones live at any moment.
• At an assumed 80 bytes a row that is 5,600 bytes, about 5.6 KB per user.
• Across 10 million accounts that is about 56 GB, which is small enough that the horizon is a product decision rather than a storage one.

The reset path is not optional. A client whose token predates retention must be told to discard its unsynced-clean state and pull the full set again, and its outbox must survive that reset untouched.

Mechanism 4. Clock skew, and what you are allowed to order by

The skew arithmetic. Assume one device's clock is 90 seconds fast, which happens through a hand-set clock or a device that has not reached a time server recently.

Under last write wins by device clock, every edit from that device beats every edit the other device made in the previous 90 seconds. The user on the correct device fixes a typo, watches it revert, fixes it again, watches it revert. The defect is systematic rather than intermittent, and it produces no error to log.

Conflict rules are chosen per field, not per app.

A worked set merge, rather than a named one. Tags on one note. Every add carries a unique add identifier, and every remove records the add identifiers it observed.

Compare the two cheaper rules on the same inputs. A plain union gives {work, urgent}, so the removed tag returns. Last writer wins on the whole tag field gives either {work, urgent} or {} depending on which device synced second, so one of the two edits vanishes. Only the per-element rule keeps both intentions.

The cost is real and worth stating: every element carries an identifier, and the remove set grows. It needs the same retention horizon and the same compaction as tombstones, for the same reason.

Mechanism 5. What resumable means after the process is killed

Three things have to be on disk before a sync starts, and one rule governs when the third of them moves.

1. The outbox rows, with their idempotency keys and their state.
2. The change token the client has fully applied.
3. Nothing else. In particular, no in-memory list of what is in flight.

The rule. A pulled batch is applied and the token is advanced in the same transaction. Then process death leaves exactly two possible outcomes: the batch and the token both landed, or neither did and the batch is refetched. Applying a batch and advancing the token separately is the bug that loses changes permanently, because the refetch will never ask for them again.

+-----------+  1 write  +===============+  2 drain  +- - - - +
| EDITOR    |---------->| LOCAL STORE   |==========>| SERVER |
| says saved|           | + OUTBOX ROW  |  by key   |        |
+-----------+           | in ONE txn    |           |        |
                        +=======+=======+           |        |
                                ^                   |        |
                        +-------+-------+  3 pull   |        |
                        | APPLY BATCH   |<==========|        |
                        | + ADVANCE     |  by token +- - - - +
                        | TOKEN, ONE txn|
                        +---------------+

Figure the sync loop. The double edged box is durable on-device state:
the note row and its outbox row commit together, so a write the editor
called saved survives process death. The pull is durable the same way,
because the applied batch and the advanced change token commit in one
transaction. The dashed box is the server, which changes without a
release. The solid arrow is work a user is waiting on and the double
arrows are deferred work nobody is waiting on

For a long resync, page it. Ask for a bounded number of entities, apply that page with its token in one transaction, then ask again. A device returning after 30 days then makes progress that survives being killed on page 7 of 40, rather than starting over each time and never finishing on a bad connection.

11d. Worked example: sync for a notes client

The prompt: notes on a phone, a tablet and the web. One person owns each note. It must work offline for up to 30 days, and no note may be lost silently.

Block 1. PURPOSE: choose the shape first, because every mechanism below is downstream of it.

One writer per note across several devices, so state sync with a per-field rule table. I say the count out loud and I say what I am rejecting: an operation log would buy character level merging inside the body, and it would cost weeks plus a permanent rebase surface, for a conflict that this product creates rarely.

I also name the condition that would change my mind: if the product later adds shared notes with two people typing, the body field alone moves to an operation log and the rest of the design survives.

The error most readers make here is choosing the shape by prestige rather than by the writer count, and then defending a CRDT for data that only one person ever writes.

Block 2. PURPOSE: make the write durable at the exact moment the interface claims it is.

One transaction writes the note row and an outbox row holding the entity identifier, the changed fields, an idempotency key generated here, the base version the edit was made against, and the state Pending.

The outbox is keyed by entity identifier plus operation type, so a second edit to the same note before the first has started sending replaces the pending row instead of queueing a second one. If the first has started, the second queues behind it with a fresh key, because it genuinely is a second operation.

The error most readers make here is generating the idempotency key in the network layer. A retry after relaunch then carries a new key, and the server sees a second note.

Block 3. PURPOSE: size the pull so that a foreground is affordable on a data plan.

Change token, not a full list. Using the 11c arithmetic, the steady state delta is about 920 bytes against about 2 MB for the full set, and at 6 foregrounds a day that is about 166 KB a month instead of about 360 MB.

The response carries changed entities, tombstones and the next token. The client applies the whole batch and advances the token in one transaction.

The error most readers make here is treating the token as a timestamp so that they can "just filter by updated_at". That loses every write that landed in the same millisecond as the cutoff and gives no way to express "too far behind".

Block 4. PURPOSE: make deletes stick, and bound what they cost.

Deletes travel as tombstones. Retention is 35 days against a 30 day offline promise, which by the 11c arithmetic is about 5.6 KB per user and about 56 GB across 10 million accounts.

A client whose token is older than retention receives the reset flag. On reset it discards its clean local state and pulls the full set, and it does not touch the outbox, because unsent local work is not stale, it is unsent.

The error most readers make here is deleting the local row on reset, outbox included. That converts a recoverable staleness problem into permanent data loss, and it is the single most expensive line of code in a sync engine.

Block 5. PURPOSE: choose a conflict rule per field, and say what the user sees for each.

The body row is the one that costs something: keeping a common ancestor per note roughly doubles the storage for the body field. That is the price of not losing a paragraph, and it is worth saying the price out loud rather than pretending the merge is free.

The error most readers make here is applying one rule to the whole entity. A note is not one value, and treating it as one is what turns a tag change into a lost paragraph.

Block 6. PURPOSE: make the whole loop survive the process being killed at the worst moment.

Nothing about what is in flight lives in memory. The outbox rows and the token are the entire state. The pull is paged, and each page commits with its own token advance, so a device returning after a month makes durable progress instead of restarting.

One measurement goes in with it: the age of the oldest pending outbox row, at the 99^th percentile. A poison row that never drains is invisible in every aggregate except that one.

The error most readers make here is testing sync by backgrounding the app. Backgrounding is the easy case. The test that matters is a force stop in the middle of an apply, repeated until the assertion that local and server agree survives it.

Result. The shape was chosen by a writer count, the write is durable in one transaction with its key, the pull costs 920 bytes instead of 2 MB, deletes travel as tombstones with a horizon that exceeds the offline promise, conflicts are resolved per field with a stated user-visible outcome, and the whole loop is resumable because the only state that matters is on disk.

11e. Fade the scaffold

Faded example 1. The prompt is a reading app that syncs highlights and the furthest read position for each book, across a phone, a tablet and an e-reader. Blocks 1 to 5 are given. Produce block 6.

• Block 1: one writer, several devices, so state sync. A highlight is immutable once created, which removes most of the conflict surface before it exists.
• Block 2: one transaction writes the highlight row and the outbox row, key generated at enqueue.
• Block 3: change token delta sync, with the same reset flag contract as 11c.
• Block 4: tombstones for deleted highlights, retention above the offline promise.
• Block 5: highlights merge as a set because they are immutable and identified. The furthest read position is the interesting field, and the rule is the maximum position rather than the last writer, because reading position only moves forward within a book.
• Block 6: you make it resumable, and you name the one thing here that a force stop can still corrupt.

Faded example 2. The prompt is a shared shopping list used by everyone in a household, where two people frequently tick items off in the same supermarket at the same time. Blocks 1 to 4 are given. Produce blocks 5 and 6.

• Block 1: several writers on the same object at the same second, so the count from 11b points away from plain state sync for the item set.
• Block 2: one transaction, outbox row, key at enqueue, unchanged.
• Block 3: change token delta sync, unchanged.
• Block 4: tombstones, with a horizon above the offline promise, unchanged.

11f. Check yourself

Q1. A photo journal app stores 900 entries at an average of 12 KB of metadata each, and currently pulls the full set on every foreground. Users foreground it 5 times a day. Assume 3 entries change between foregrounds, that a changed entry sends 250 bytes of fields, and that the envelope and token cost 120 bytes. Quantify the change, then say which mechanism you would ship first.

Q2. A colleague proposes dropping the change token and instead sending ?since=<the client's last updated_at>, filtering server side on the entity's updated_at column. Evaluate it.

11g. When not to use this

A sync engine is the most expensive subsystem on this page to build and the most expensive to operate, and it is proposed far more often than it is needed.

Module 12. Storage and caching tiers on device

Time: 45 to 55 minutes reading, 30 to 40 minutes practice.

Every mobile app has four or five storage tiers whether anyone designed them or not. This module makes the choice explicit, sizes each tier from a device number rather than a guess, and answers the question that separates a described client from a designed one: what exactly survives, and what exactly does not.

12a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| STORAGE AUDIT of a shipping feed app                          |
|   key-value prefs  refresh_token, user_id, and one cached     |
|                    feed JSON blob of 180 KB                   |
|   cache directory  decoded image files, 640 MB, no cap        |
|   app data dir     feed.sqlite, 40 MB, included in backups    |
|   memory cache     up to 100 decoded full-screen bitmaps      |
| Device facts                                                  |
|   heap ceiling for this process  256 MB                       |
|   screen 1080 x 2340 pixels, 4 bytes per pixel                |
+---------------------------------------------------------------+
Caption: four storage tiers as actually configured, with the two
device numbers that decide whether the memory tier is legal.

Question. Compute how many images the user can scroll past before the process is killed, and separately name the tier that leaks a secret onto a different device.

The tier table, which is the module in one screen.

One rule that resolves most arguments: nothing on the device is durable. The OS may clear caches, the user may clear data, a restore may or may not carry a tier, and reinstall behaviour differs by platform and changes between versions. Design so the only durable tier is the server, and treat every local tier as an optimisation that can vanish between two launches. Then reinstall behaviour becomes a detail rather than a correctness dependency.

Classify data before choosing a tier. Four durability classes cover almost everything, and the class determines the tier mechanically.

Class D deserves a sentence because it is the one nobody plans for. Your process can be killed while backgrounded and recreated on the same screen. If interface state lives only in memory, the user returns to the top of the feed with a cleared form, and the crash reporter shows nothing because there was no crash.

Sizing the memory tier from the frame budget, not from a round number.

• Cell image at display size 1080 x 600 x 4 bytes = 2.59 MB
• Heap ceiling assumed 256 MB for a mid-tier device, which is why we design for it rather than for the flagship in your pocket
• Interface, framework and application objects, assume they take half the heap, leaving 128 MB
• Give the bitmap cache at most a quarter of what remains: 32 MB
• 32 / 2.59 = 12 cells, which is roughly two screens of scroll history

Twelve is a small number, and that is the honest result. It says the memory tier is a scroll-reversal optimisation, not a browsing history, and that the disk tier is what makes scrolling back feel instant.

Sizing the disk tier from the working set.

• Images viewed per session, assumed from scroll analytics: 200
• Encoded bytes per image at the delivered resolution, assumed: 150 KB
• One session's working set: 200 x 150 KB = 30 MB
• Cap at two sessions, so 60 MB, because re-viewing content older than the previous session is rare on a feed

Then measure the hit-rate curve and move the cap to the knee. A cap chosen from a curve is defensible in a design review. A cap of "512 MB because that seemed fine" has no answer to the only follow-up it invites, which is why that number.

Eviction, compared on what each one actually optimises.

The working answer is two caps and two policies: least recently used for space, and a per-entry validator for freshness. They answer different questions, and conflating them produces caches that serve stale data and evict fresh data at the same time.

Embedded database facts that change a design.

• Batch writes in one transaction. Assume a durable commit costs 2 ms. One thousand individual inserts is 1,000 commits, so about 2 seconds. The same thousand inserts inside one transaction is one commit, so about 2 ms. This is a thousandfold difference and it is one line of code.
• Every index you add is paid on every write to that table. Add indexes from measured query plans, not from intuition.
• Never migrate a cache. If a schema change affects a table holding class A data, drop the table and refetch. Migration code is the most-bug-prone code in a client, and writing it for data the server already holds is wasted risk.
• Whole-database encryption is paid on every page read, so measure your query latency with it on before adopting it. Encrypting only the sensitive columns is often the better trade, and it is a decision, not an omission.

+---------------------------------------------------------------+
| MEMORY CACHE      capped in bytes, dies with the process      |
+---------------------------------------------------------------+
              |  miss                          ^ promote
              v                                |
+---------------------------------------------------------------+
| DISK CACHE DIR    capped, OS may evict, refetchable only      |
+---------------------------------------------------------------+
              |  miss
              v
+---------------------------------------------------------------+
| APP DATA DIR      user-authored, backed up, never auto-evicted|
+---------------------------------------------------------------+
              |  secrets only
              v
+---------------------------------------------------------------+
| KEY STORE         keys and tokens, excluded from backup       |
+---------------------------------------------------------------+
Caption: four on-device tiers ordered by durability. A miss falls
to the tier below, and only the bottom two hold anything whose
loss the user would notice.

12d. Worked example

The prompt. "Plan the on-device storage for a feed app that also lets people write and post. It must open to content with no network."

Inputs stated first:

Block A. Purpose: assign every piece of data a durability class

I write the class table before I name a single storage technology, because the class decides the technology.

I say the interesting consequence out loud: the feed database goes in the cache directory, not the app data directory. It can be evicted by the OS under storage pressure and that is correct, because the alternative is an app that consumes gigabytes of a user's phone to hold content the server already has.

The error most readers make here. Putting everything in one database in the app data directory. That mixes class A and class B, so the cache is backed up (wasting the user's backup quota on refetchable data) and the drafts inherit the cache's eviction and migration behaviour.

Block B. Purpose: size the memory tier so the process survives

From the device facts: at 1080 x 600 display size and 4 bytes per pixel, one decoded cell image is 2.59 MB. I budget 32 MB, derived earlier as a quarter of the half of the heap that is not already interface objects, giving 12 entries.

I then check that 12 is enough for the actual interaction. During a fling the list binds maybe 3 cells per frame and the user reverses direction within a screen or two. Twelve entries covers roughly two screens, so scroll reversal hits memory and longer journeys hit disk. That is the intended behaviour, and I state it as intended rather than letting it look like an accident.

Two hard rules I attach:

• The cap is in bytes, never in entries, because bitmap size varies by cell type and a count-based cap silently becomes a 10x memory swing.
• On a memory-pressure callback, the memory tier is cleared entirely and first, before anything else is dropped, because it is the only tier whose loss costs nothing but a disk read.

The error most readers make here. Sizing the memory cache from the source image dimensions. A 4000 x 3000 source decodes to 48 MB. Decoding at source size and then scaling for display is the single most common cause of client out-of-memory kills, and it is invisible on a developer's flagship device.

Block C. Purpose: size and cap the disk tier from the working set

Two separate caches, because they have different lifetimes:

The 60 MB comes from the working set arithmetic: one session is 200 x 150 KB = 30 MB, and two sessions of history is 60 MB. The 200 items comes from the offline requirement: opening to content means the last two screens plus enough to scroll for a minute, and 200 items at an assumed 8 items per screen is 25 screens, which is generous.

I also state what I will measure to revise these: cache hit rate against cap, at 30, 60 and 120 MB. If hit rate at 120 MB is within 2 points of 60 MB, the extra 60 MB of the user's phone buys nothing and I keep the smaller cap.

The error most readers make here. Letting the image cache grow without a cap because "the OS will clear it". The OS clears it at its convenience, usually when the device is already nearly full, and until then your app is the one showing up at the top of the storage settings screen. Users uninstall for this.

Block D. Purpose: decide the secret tier and the backup contract

Three decisions, each with the reason attached:

• The refresh token goes in the key store, flagged so it does not migrate to a restored device. A credential that survives a restore turns a stolen backup into a session.
• The short-lived access token lives in memory only. It expires in minutes, so persisting it buys nothing and adds a place it can leak from.
• Backup inclusion is explicit per directory. Class B data (drafts) is backed up. Class A data (feed cache, images) is excluded. Class C never.

I say the number that makes this concrete: excluding a 60 MB image cache from backup saves the user 60 MB of backup quota per device, per backup, to protect data the server can send again in seconds.

The error most readers make here. Treating "encrypted" as a property of the file rather than of the key. If the encryption key sits next to the encrypted file in the same backed-up directory, you have added a compute cost and no security. The key store exists precisely so the key lives somewhere the file does not.

Block E. Purpose: define the three destructive events before someone else does

The draft case is the one worth arguing in an interview. Silently deleting unsynced user writing on logout is data loss caused by a design decision. Uploading it first, or blocking logout behind a clear prompt, is a product decision that an engineer should raise, and raising it is a senior signal.

The error most readers make here. Implementing logout as "delete the token". The session ends, the cached content does not, and the next sign-in on that device shows a different user's feed for the seconds before a refresh lands.

12e. Fade the scaffold

Fade 1: offline map regions. Users download a city region for offline use. Tiles are large, immutable once downloaded, and a region can be hundreds of megabytes. Same five-block shape, last block blank.

• Block A, durability classes: downloaded tiles are class B even though the server can regenerate them, because the user explicitly asked for them and re-downloading a 400 MB region on a metered connection is a real cost. Style and search caches remain class A.
• Block B, memory tier: hold decoded tiles for the visible viewport plus one ring. At an assumed 256 x 256 tile and 4 bytes per pixel, one tile is 262 KB, and a viewport plus ring of 25 tiles is 6.6 MB. Cap in bytes, clear on memory warning.
• Block C, disk tier: regions go in the app data directory, excluded from backup because they are huge and refetchable, with per-region accounting so the user can see and delete each region by name.
• Block D, secrets and backup: no secrets beyond the API credential. Exclude every region from backup. Store the region manifest, not the tiles, in a small database so the app can list regions before touching the tile store.
• Block E, destructive events: you write this block.

Fade 2: a podcast client with offline episode downloads. Episodes are large audio files, users subscribe to shows, and playback position must survive everything. Last two blocks blank.

• Block A, durability classes: episode audio is class B (explicitly downloaded). Show and episode metadata is class A. Playback position is class B and tiny, and it is the single most emotionally important byte in the product.
• Block B, memory tier: almost nothing. Audio streams from disk, so the memory tier holds artwork only, capped in bytes at an assumed 8 MB, which at 1080 x 1080 x 4 = 4.4 MB per full-size image means artwork must be decoded at display size or the cap holds fewer than two images.
• Block C, disk tier: you write this block.
• Block D, secrets and backup: you write this block.

12f. Check yourself

Q1. Explain, with a number, why a bitmap memory cache must be capped in bytes rather than in entries, using a screen of 1080 x 2340 and a mix of full-bleed cells and 120 pixel tall thumbnails.

Q2. Your feed database lives in the cache directory. A teammate reports that after an OS storage cleanup, the app opens to an empty feed instead of the user's cached content, and wants to move the database to the app data directory. Give the argument for and against, and state what you would actually do.

12g. When not to use this

An embedded relational database.

A three-tier cache (memory, disk, network).

Whole-database encryption at rest.

A custom eviction policy.

Module 13. Lifecycle, background execution and battery

Time: 50 to 60 minutes reading, 35 to 45 minutes practice.

The operating system is an adversary with good intentions. It will suspend your process, defer your work, batch your alarms and kill you for memory, and it will do none of it at a time you chose. This module turns that into arithmetic: a battery budget, a wakeup allowance, and a job classification that follows from both.

13a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| BACKGROUND SYNC v0                                            |
|   A periodic job every 15 minutes, all day                    |
|   Each run holds a wake lock, opens a connection, fetches     |
|   20 KB, writes the database, releases                        |
|   Active work per run: 1.2 seconds                            |
| Assumed device and radio facts                                |
|   Battery 3000 mAh at 3.85 V                                  |
|   Cellular radio holds a high-power state about 10 s after    |
|   the last packet, then steps down                            |
|   Average power while the radio is up: 500 mW                 |
+---------------------------------------------------------------+
Caption: a fifteen-minute periodic sync, with the two radio facts
that decide what it actually costs.

Question. Compute the share of a full battery this consumes per day, then name which of its costs dominates and what that implies for the fix.

The process state ladder, and what each step takes away.

Two consequences to state in an interview, because they are the ones candidates miss:

• Every background unit of work must be idempotent and resumable, because it will be killed mid-run and re-run later. A job that assumes it finishes is a job that corrupts something eventually.
• There is no reliable "run at time T" for a backgrounded app. You express constraints and the OS chooses. Design the product around "eventually, and batched with other work", or move the work to the server and push the result.

Classify the work first. The mechanism follows.

The fourth row is the senior move. A large fraction of background work on clients exists because someone put a loop on the device instead of asking the server to compute the answer and notify. "Move it to the server" should be your first proposal, and the reason to reject it (privacy, offline capability, data the server does not have) should be a stated reason rather than an omission.

Riding an existing wakeup, priced. The 5.6 J figure was for an isolated wakeup that pays the full radio promotion and tail. If your work runs while the radio is already up (a push just arrived, the user just foregrounded the app, another app woke the radio and the OS batched you alongside), you pay only the active seconds.

• Isolated wakeup, 1.2 s of work: 11.2 s of radio at 0.5 W = 5.6 J
• Riding an existing wakeup, same work: 1.2 s at 0.5 W = 0.6 J
• Ratio: 9.3 to 1

That ratio is the entire argument for coalescing, and it is why "sync on push arrival" beats "sync every fifteen minutes" even when the push carries no data.

The four drain sources a client actually controls.

Relative cost, so you can prioritise. Treat this ordering as an assumption to be confirmed on your own hardware, but it is stable enough to reason with: for the same wall-clock second, the screen at high brightness costs the most, then the cellular radio in its high-power state, then continuous satellite location, then wifi, then a busy CPU core. The ordering matters more than the exact numbers, because it tells you that a feature which keeps the screen on is a battery feature before it is anything else.

Low-power mode: a policy table, not a flag check. When the OS signals a constrained state, decide in advance what degrades and in what order.

State the ordering rule too: degrade things the user cannot see before things they can, and never degrade a thing the user explicitly asked for. Deferring a user's photo upload because the battery is low is defensible only if the app says so on screen.

Measuring it, with the limits of each method.

Size the A/B before running it. Assume drain per foreground hour has a standard deviation of 8 percentage points across users, and you want to detect a 1 point regression at conventional power:

• n per arm = 2 x sigma squared x (z_alpha + z_beta) squared / delta squared
• = 2 x 64 x (1.96 + 0.84) squared / 1
• = 2 x 64 x 7.84 = 1,004 users per arm

So roughly a thousand users per arm detects a one point change. If your rollout stage is smaller than that, your battery A/B is decorative, and knowing that before you run it is the difference between a measurement and a ritual.

+---------------------------------------------------------------+
| WHAT IS THE WORK FOR                                          |
+-------+-----------------+---------------+---------------------+
        |                 |               |
        v                 v               v
+---------------+ +---------------+ +-----------------------+
| USER WATCHING | | USER ASKED,   | | NOBODY ASKED          |
| visible task  | | can wait      | | prefetch, cleanup     |
| show progress | | constrained   | | ride an existing      |
| and a stop    | | deferrable    | | wakeup or drop it     |
+---------------+ +-------+-------+ +-----------+-----------+
                          |                     |
                          v                     v
                  +---------------------------------------+
                  | CAN THE SERVER DO IT INSTEAD          |
                  | if yes, do it there and push          |
                  +---------------------------------------+
Caption: classify background work by who is waiting for it, then
ask whether the device needs to be involved at all.

13d. Worked example

The prompt. "Our messaging client is being blamed for battery drain. Give it a background design that fits inside 1 percent of a battery per day."

Inputs, stated before any design:

Block A. Purpose: turn the budget into a wakeup allowance

One percent of 41,580 J is 415.8 J per day. That is the entire background allowance, and every job has to be paid out of it. I split it before designing anything, because an unsplit budget is always overspent:

Now convert to units I can design with. At 5.6 J for an isolated wakeup, the whole 415.8 J buys 74 isolated wakeups a day. At 0.6 J per second of work riding an existing wakeup, the same budget buys nearly 700 seconds of work. The design question is therefore not "how much work" but "how much of the work can ride something that was going to happen anyway".

The error most readers make here. Starting from the feature list and adding up. Start from the budget and divide it. A budget that is allocated before design forces the trade-offs into the open, and the interviewer can see you making them.

Block B. Purpose: classify every background job against the ladder

Total: 30 + 20 + 11.2 + 5 = 66.2 J, which is 0.16 percent of the battery, well inside the 1 percent budget. The headroom is deliberate: field conditions are worse than assumptions, and radios in poor signal draw more for longer.

The row that carries the design is the first one. Because a push already wakes the device and brings the radio up, fetching the message body in that window costs 0.3 s of active radio rather than a full 11.2 s cycle. Two hundred fetches cost 30 J instead of 1,120 J. That is the difference between a 0.07 percent feature and a 2.7 percent feature, and it is entirely about when, not what.

The error most readers make here. Designing a polling loop as a fallback "in case push fails" and leaving it always on. A safety-net poll every 15 minutes costs 537 J a day, which is more than the entire budget, to cover a failure mode that occurs on a small fraction of devices. Make the fallback conditional: poll only after an assumed 6 hours with no push received, which costs 4 wakeups a day in the worst case.

Block C. Purpose: attach every remaining job to an existing wakeup

Four wakeup sources already exist. I list them and assign work to each, so no job invents a schedule of its own:

The rule I state: no feature gets its own timer. New background work must name which existing wakeup it rides, or justify a new one against the budget. This is a process rule as much as a technical one, and it is the only thing that stops background cost from creeping back up over four quarters.

The error most readers make here. Treating each feature's background work as independently reasonable. Every one of six features scheduling "just a small 15 minute job" produces 576 wakeups a day. The cost is superlinear in team size unless someone owns the total.

Block D. Purpose: define the degradation ladder before the OS forces it

Three constrained states, each with a defined behaviour:

The invariant across all three: message delivery, which is the product, never degrades. Everything else is negotiable. Writing the invariant down first makes the rest of the table fall out mechanically, and it gives you a one-sentence answer when the interviewer asks what you would cut.

The error most readers make here. Deferring the user's own outgoing media silently. If the app decides to hold a photo until wifi, the user must see that decision on the message row. A silent deferral looks exactly like a bug, and users retry, which costs more energy than sending it would have.

Block E. Purpose: instrument so the number can be defended

Four counters, emitted with the telemetry that already flushes opportunistically:

I set the regression alert on wakeups per day rather than on battery, because wakeups move immediately when someone adds a timer, while battery drain is noisy and lagging. Assume a baseline of 12 wakeups a day per user at p50; alert when p50 exceeds 18, which is a 50 percent increase and far outside ordinary behavioural variation.

The error most readers make here. Reporting only the mean. Background cost is a tail problem: a small cohort with a retry loop, a poison outbox entry or a failing job burns hundreds of wakeups a day while the mean barely moves. Report p50, p95 and p99, and alert on p95.

13e. Fade the scaffold

Fade 1: a fitness app that records a workout. Location is sampled during a run, the screen is usually off, and the recording must survive the app being backgrounded for an hour. Same five-block shape, last block blank.

• Block A, budget: this is user-initiated and user-visible, so the budget is far larger than 1 percent. State it as a product number: an assumed 8 percent of battery per hour of recording is acceptable for a workout tracker because the user chose to start it and can see it running.
• Block B, classification: location sampling is a user-visible foreground task with a persistent indicator, not deferrable work. Uploading the finished workout is user-initiated deferrable. Fetching route suggestions is opportunistic and should be off during recording.
• Block C, ride existing wakeups: nothing rides anything here, because the recording itself is the continuous cost. The lever is sampling rate: at an assumed 1 Hz high-accuracy sampling versus 0.2 Hz with a 10 metre distance filter, the second sends the location subsystem to sleep between fixes and cuts its share substantially. Measure both on a rig.
• Block D, degradation: on low-power mode, keep recording at reduced sampling and say so on screen. Never silently stop a recording, because losing a user's marathon is unrecoverable and unforgivable.
• Block E, instrumentation: you write this block.

Fade 2: an email client with three configured accounts. Users expect new mail to appear without opening the app, two of the accounts support push and one does not. Last two blocks blank.

• Block A, budget: assume a 1.5 percent daily background allowance, slightly above the messaging client because mail is a background-first product, so 415.8 J becomes 624 J.
• Block B, classification: pushed accounts are the messaging case and cost almost nothing. The non-push account requires polling, which is the entire problem, and it must be budgeted separately and visibly.
• Block C, ride existing wakeups: you write this block.
• Block D, degradation: you write this block.

13f. Check yourself

Q1. A colleague proposes replacing your push-triggered fetch with a 5 minute polling job "so freshness is predictable". Using the joule figures from this module, compute the daily cost and state the freshness the poll actually delivers.

Q2. Your background job is killed roughly 30 percent of the time before it completes. Name the two design properties the job must have, and describe what goes wrong for a media upload job that has neither.

13g. When not to use this

A background job at all.

Push-triggered background fetch.

A polling fallback.

A foreground task with a visible indicator.

Module 14. Concurrency and memory

Time: 45 to 55 minutes reading, 35 to 45 minutes practice.

A client has one thread that is allowed to touch the screen and a hard deadline that arrives 60, 90 or 120 times a second. Every concurrency decision in a mobile app is downstream of that. This module turns "do work off the main thread" into arithmetic, then does the same for memory.

14a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| FEED ROW BINDING, as written today                            |
|   onBind(row):                                                |
|     bytes = readFileFromCache(row.id)          3 ms           |
|     model = parseJson(bytes)                   4 ms           |
|     applyValuesToViews(model)                  1 ms           |
| Facts measured on the target device                           |
|   Display refresh rate 90 Hz                                  |
|   During a fling the list binds 3 new rows per frame          |
|   Measure, layout and draw cost 2 ms on top of binding        |
+---------------------------------------------------------------+
Caption: a row binding that does disk and parse work inline, with
the refresh rate and bind rate that turn it into dropped frames.

Question. Compute the frame rate the user actually sees during a fling, and name the second failure this code will produce that a frame trace will not show.

What must, must not, and may run on the main thread.

Frame budgets, with the headroom rule.

The 70 percent figure is an operating convention rather than a law, and here is why it is reasonable: your process does not own the device, and a budget set at 100 percent of the interval is a budget that is exceeded whenever anything else happens. Setting it at 70 percent means ordinary system noise does not produce a dropped frame.

The rule that fixes most feed performance: bind is not the place to compute. Move work to whichever of these is earliest and cheapest:

Applying that to the artefact: parse the page once when it arrives, hold display models in memory, and binding becomes the 1 ms assignment step. Work per frame drops from 26 ms to 3 x 1 + 2 = 5 ms, which fits inside the 7.8 ms usable budget at 90 Hz with room left.

Sizing thread pools, rather than picking eight.

Little's law is worth stating out loud in an interview because it converts a guess into a derivation: if you want to sustain 20 requests per second and each takes 200 ms, you need 4 in flight. Asking for 32 in-flight requests does not make the network faster, it makes 28 of them wait somewhere less visible.

Structured concurrency, in one paragraph. Tie every task to the lifetime of the thing that asked for it: a screen, a row, a request. When the screen goes away, its scope is cancelled and every child task is cancelled with it. The benefit is not elegance, it is that you can no longer forget, because forgetting requires deliberately launching outside the scope.

Cancellation is cooperative, which is the trap. A cancelled task does not stop. It is marked cancelled and stops at the next point that checks. A tight decode loop or a synchronous socket read checks nothing and runs to completion. Two practical rules:

• Check for cancellation between units of work, and make the units small enough that the check happens within a frame or two.
• Pass cancellation into libraries that support it (request cancellation on the networking client, decoder abort flags) rather than relying on your own loop.

Pricing cancellation. During a fast fling a feed can start decoding an image for every row it binds. Assume 200 rows fly past, 20 of which stop on screen, and each decode costs 15 ms of CPU and allocates 2.6 MB.

• Without cancellation: 200 x 15 ms = 3.0 s of CPU and 520 MB of allocation churn, all of it competing with the frames the user is watching
• With cancellation on recycle: roughly 20 useful decodes, so 0.3 s and 52 MB
• Ratio: 10 to 1, and the wasted 90 percent lands precisely when the device is busiest

Memory: the numbers that decide a design.

Five leaks that account for most client memory bugs.

The detection pattern worth naming: after a screen is destroyed, hold a weak reference to it, run a collection, and if it is still reachable, capture the reference path. This finds the first three rows automatically and is cheap enough to leave on in development builds for everyone.

Responding to memory pressure, as a ladder.

The invariant is the last cell: never discard class B data (user-authored and unsynced, from Module 12) to relieve memory pressure. Everything else is a cache and can be rebuilt.

+-------------------+   post results only   +-------------------+
| MAIN THREAD       | <==================== | CPU POOL, size 6  |
| views, layout     |                       | parse, decode     |
| assign values     |                       | compress          |
+-------------------+                       +-------------------+
        ^                                            ^
        | cancel on destroy                          |
+-------+-----------+                       +--------+----------+
| SCREEN SCOPE      | ====================> | NETWORK POOL, 4   |
| owns every task   |   launch and cancel   | in-flight limit   |
+-------------------+                       +-------------------+
        |
        v
+-------------------+                       +-------------------+
| DISK POOL, size 2 | ====================> | DB WRITE QUEUE, 1 |
| file reads        |                       | serial, batched   |
+-------------------+                       +-------------------+
Caption: one screen scope owns every task it starts, four pools are
sized by what they contend for, and only assignment happens on the
main thread.

14d. Worked example

The prompt. "Our feed drops frames on mid-range devices and runs out of memory on 2 GB devices. Redesign the concurrency and memory model."

Inputs before any change:

Block A. Purpose: measure before changing anything

I ask for three artefacts before I touch code, and I say why each one is necessary rather than nice:

I state the discriminator up front: if frame drops line up with collection events, the problem is allocation churn and the fix is to stop allocating in bind. If they line up with long function bodies, the problem is compute and the fix is to move it. Guessing between those two is how a week disappears.

The error most readers make here. Optimising the function that looks expensive. The function inside the dropped frames is often not the slowest function in the app, and the two are found by different tools.

Block B. Purpose: empty the bind path

Current cost per frame: 3 x 8 + 2 = 26 ms against a 7.8 ms usable budget, so I need to remove roughly 21 ms.

New cost per frame: 3 x 1 + 2 = 5 ms, inside the 7.8 ms budget with 2.8 ms of headroom. That headroom is not slack, it is the allowance for the p99 cases, and I say so.

The memory consequence has to be checked in the same breath, because I have traded time for space. A display model at an assumed 1.5 KB, for 200 cached items, is 300 KB. That is negligible, so the trade is free. If the model had been 100 KB per item I would have had to hold models only for a window around the viewport, and that is a different design.

The error most readers make here. Moving the parse to a background thread but leaving it in bind. Now bind returns immediately, the row renders empty, and the content arrives a frame or two later, so the user sees flickering placeholders during every fling. Off the main thread is not the same as out of the bind path.

Block C. Purpose: size the pools and serialise the database

Four pools, each sized by what it contends for rather than by taste:

I add one rule that matters more than the sizes: image decode gets its own bounded queue with a depth cap, an assumed 8 entries, and newest-first ordering. During a fling the newest request is for a row the user is about to see, and the oldest is for a row that has already left the screen. A first-in-first-out decode queue spends the whole fling decoding rows nobody will look at.

The error most readers make here. Using one large shared pool for everything. A burst of image decodes then starves the network calls that feed the next page, so the list runs out of content precisely when the user is scrolling fastest. Pools are not just about thread count, they are about isolation.

Block D. Purpose: make cancellation actually happen

Three scopes, each tied to a lifetime the framework already manages:

The row scope is the one that pays. Using the earlier arithmetic, cancelling on recycle takes a fling from 200 decodes to roughly 20, which is 3.0 s of CPU down to 0.3 s and 520 MB of churn down to 52 MB.

I check the cooperative-cancellation trap explicitly: the decoder must be given an abort signal, and the loop that resizes must check between rows of pixels, not only at the end. A cancelled task that runs to completion has cost exactly as much as an uncancelled one and is harder to reason about.

The error most readers make here. Cancelling the wrong scope. Cancelling page fetches on row recycle means fast scrolling repeatedly kills the request that would have supplied the next page, and the list stalls at the bottom. Match each task to the lifetime that genuinely bounds it.

Block E. Purpose: bound memory and detect the leak

Two mechanisms, one for footprint and one for leaks.

Footprint: the bitmap cache is capped in bytes at 32 MB, derived in Module 12 from the heap ceiling, and the pressure ladder drops it first. Display models are held for a window of an assumed 200 items and trimmed on each refresh.

Leaks: a weak-reference watcher registers every destroyed screen and row holder, forces a collection after an assumed 5 second delay, and captures a reference path if the object is still reachable. In development builds this fails the test suite. In release builds it reports a counter, not a dump, because a heap dump on a user's device is both slow and full of their data.

The one number I would put on a dashboard: process kills while backgrounded, as a share of sessions. It converts memory footprint into a user-visible outcome, namely how often reopening the app restarts it from cold instead of resuming.

The error most readers make here. Shipping the leak detector's full dump capability to production. It captures user data, it takes seconds, and it usually triggers on the slowest devices. Report the fact of the leak in production and capture the detail in development.

14e. Fade the scaffold

Fade 1: a map screen that decodes and composites tiles. Tiles arrive over the network, decode to 256 x 256 x 4 = 262 KB each, and the visible viewport plus one ring is 25 tiles. Same five-block shape, last block blank.

• Block A, measure first: frame trace during a pan and a pinch-zoom, allocation timeline across a zoom level change (the worst case, because every tile is replaced at once), heap dump after ten screen visits.
• Block B, empty the draw path: tiles are decoded on the CPU pool and uploaded as textures ahead of being needed. Drawing assigns already-decoded tiles only. A zoom level change must reuse the previous level's tiles scaled, so the screen is never blank while the new level decodes.
• Block C, pool sizing: network pool sized by Little's law at an assumed 30 tile requests per second and 150 ms latency, so 4 to 5 in flight. Decode pool of 6. Decode queue ordered by distance from the viewport centre, not by arrival.
• Block D, cancellation: tiles outside the viewport plus ring are cancelled on every pan step. During a fast pan this is the dominant saving, exactly as row recycle was in the feed.
• Block E, memory and leak detection: you write this block.

Fade 2: a chat screen that decrypts each message before rendering. Messages are end-to-end encrypted, decryption costs an assumed 0.4 ms per message on the target device, and a conversation opens showing the last 50 messages. Last two blocks blank.

• Block A, measure first: trace the open of a long conversation, which is the worst case, and separately trace scrolling upward through history. Check whether frame drops coincide with collections, because a per-message decryption that allocates a new buffer each time is an allocation problem wearing a compute costume.
• Block B, empty the bind path: 50 messages at 0.4 ms is 20 ms of decryption on open. That is a visible stall on a screen the user just tapped into. Decrypt off the main thread, in a batch, before the screen presents, and cache the plaintext in memory keyed by message identifier so scrolling back never decrypts twice.
• Block C, pool sizing: you write this block.
• Block D, cancellation: you write this block.

14f. Check yourself

Q1. A colleague raises the disk pool from 2 threads to 12 to "speed up loading". Predict what happens to median and p99 read latency and explain the mechanism in two sentences.

Q2. You cancel an image decode when a row is recycled, but the trace shows the decode still running to completion 40 ms later. Give the mechanism and the smallest fix.

14g. When not to use this

Custom thread pools.

Structured concurrency scoping down to the row level.

Object pooling to avoid allocation.

A leak watcher running in production builds.

Module 15. Platform variation

Time: 35 to 45 minutes reading, 25 to 35 minutes practice.

Most course material on this topic is either a list of API names with no consequence, or a shrug that says the platforms are basically the same. Both are useless in an interview. This module states the four differences that change an architecture, treats everything else as naming, and gives the cross-platform answer honestly.

15a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| DESIGN DOC EXCERPT, submitted for review                      |
|   1. A background service syncs every 15 minutes on both      |
|      platforms.                                               |
|   2. We hold a websocket open while the app is backgrounded   |
|      so messages arrive instantly.                            |
|   3. Tokens go in the platform preferences store, which is    |
|      equivalent on both sides.                                |
|   4. The same permission prompt copy ships on both, shown at  |
|      first launch.                                            |
+---------------------------------------------------------------+
Caption: four cross-platform claims from a design review, three
of which do not survive contact with an operating system.

Question. For each numbered claim, say whether it holds, and for the ones that do not, name the architectural consequence rather than the API.

The four differences that change an architecture. Everything else on the comparison tables below is naming, and naming is worth thirty seconds in an interview. These four are worth ten minutes.

Execution and scheduling.

Storage, security and privacy.

Networking, push and delivery.

Interface, state and concurrency.

The cross-platform column, without the marketing. Three honest statements:

• The shared layer that pays is the one with no operating system in it: models, the sync engine, validation, the retry and backoff policy, feature flag evaluation, and the display-model transformation from Module 14.
• The layer that does not pay is anything touching background execution, push registration, secure storage, permissions, or system interface conventions. Every serious cross-platform app writes native code for these, and the question is only whether you admit it in the design.
• The costs to price are startup time, binary size, and the debugging surface of the bridge between the two worlds. Ask for measurements of all three from the team proposing the stack, and if none exist, that is the finding.

+---------------------------------------------------------------+
| SHARED CORE, no operating system calls                        |
| models, sync engine, retry policy, flag evaluation, display   |
| model transforms, validation                                  |
+-------------------------------+-------------------------------+
                                |
        +-----------------------+-----------------------+
        v                                               v
+----------------------------+          +----------------------------+
| PLATFORM SHELL A           |          | PLATFORM SHELL B           |
| scheduling, push, keystore |          | scheduling, push, keychain |
| permissions, navigation    |          | permissions, navigation    |
| interface toolkit          |          | interface toolkit          |
+----------------------------+          +----------------------------+
Caption: the sharing line sits exactly where operating system calls
begin. Everything above it is one implementation, everything below
is two.

15d. Worked example

The prompt. "One team has to ship an offline-capable notes client on both platforms. Decide what is shared and what is not."

Inputs, stated first:

Block A. Purpose: draw the sharing line by asking one question per component

The question is not "can this be shared" but "does this call the operating system". I go component by component:

Result: the 45 percent core is genuinely shared, the 20 percent platform layer is genuinely not, and the 35 percent interface layer is the actual decision. That framing turns a religious argument into a scoped one.

The error most readers make here. Debating the framework before drawing the line. The line is a property of the app, not of the framework, and once it is drawn the framework choice is mostly about the interface layer.

Block B. Purpose: decide the interface layer by pricing it, not by taste

Two candidate shapes, priced against the inputs:

The measurements I would demand before choosing the second row, with the threshold attached:

• Cold start delta from the runtime. Budget is 500 ms, so a runtime that adds more than an assumed 150 ms (30 percent of the budget) has to be justified by something bigger than code sharing.
• Binary size delta. Set a budget in advance, for example an assumed 8 MB, and hold it, because size affects install conversion on constrained networks.
• Frame timing on the target mid device for the scrolling list, measured, not demonstrated on a flagship.

With 6 engineers and a parity requirement, I would lean to the shared interface and hold it to those three numbers, and I would say plainly that if any of the three fails, native interfaces are the answer and the core sharing still stands. Notice what did not decide it: nobody's preference.

The error most readers make here. Treating cross-platform as all or nothing. The core sharing decision and the interface sharing decision are independent, and the first one is nearly always worth taking.

Block C. Purpose: fork the four architecture-changing differences explicitly

These get named as separate work items with owners, because they are where "shared" quietly becomes wrong:

The right-hand column is the one to say out loud. Each of these differences forks an implementation while leaving a policy shared, and separating policy from mechanism is what keeps two platform builds behaving the same.

The error most readers make here. Abstracting the platform difference away behind a single interface such as Scheduler.schedule(job, every: 15.minutes). The abstraction implies a guarantee neither platform gives, so it teaches every future engineer something false. Abstract at the level of "run this eventually, when there is network", which both platforms can honour.

Block D. Purpose: define the contract between core and shell

Four rules, each preventing a specific failure:

Rule three has a payoff worth quantifying: with those interfaces injected, the whole sync engine runs in a plain test process with a fake clock and a fake network. A conflict-resolution suite that would take minutes on two device farms runs in seconds on a build machine, which is what makes it get run.

The error most readers make here. Letting the shell reach into the core's storage directly for a quick fix. Once that happens twice, the sharing line is gone and every future change costs two implementations plus a coordination problem.

Block E. Purpose: state the testing and release consequence

The last row is the one that is easiest to leave out. Your server contract's compatibility window is not a per-platform decision. It is set by whichever platform's users update most slowly, and that is a fact you look up rather than assume.

The error most readers make here. Testing the forked layer only on the platform the author works on. The four architecture-changing differences are exactly the places where a bug is invisible from the other side, and they need explicit device coverage on both.

15e. Fade the scaffold

Fade 1: a camera-heavy app shipping on both platforms. Capture, on-device processing, and upload. Same five-block shape, last block blank.

• Block A, sharing line: the processing pipeline definition, the upload queue, the retry policy and the metadata model are shared. Capture, camera configuration, hardware capability queries and the media library are native, because camera stacks differ far more than storage does.
• Block B, interface decision: the capture screen is native on both regardless of the rest, because it is latency-sensitive, gesture-heavy and full of platform-specific hardware behaviour. Everything after capture (review, edit, share) is a candidate for sharing.
• Block C, forked differences: background upload is the big one. It must continue after the app leaves the screen, which means a foreground task on one platform and a system-managed transfer session on the other, with the same resumable protocol underneath.
• Block D, core to shell contract: the core owns the upload state machine and exposes a snapshot per asset (queued, uploading, failed, done). The shell owns progress display and any system-level indicator.
• Block E, testing and release consequence: you write this block.

Fade 2: a payments software development kit shipped to third-party apps on both platforms. Last two blocks blank.

• Block A, sharing line: the protocol, the state machine, the error taxonomy and the retry policy are shared. Everything the host app can see (the public API shape, the threading contract, the error type) is deliberately native and idiomatic on each platform, because an SDK that feels foreign is an SDK people avoid.
• Block B, interface decision: any prebuilt screens are native. A cross-platform runtime inside someone else's app is a large imposition of binary size and startup cost on a host that did not choose it.
• Block C, forked differences: you write this block.
• Block D, core to shell contract: you write this block.

15f. Check yourself

Q1. An interviewer works on the platform you do not. Give the two sentences you would say in the first minute, and explain what each one buys you.

Q2. A team proposes moving to a cross-platform stack to halve their client work. Name the three measurements you would ask for and give the threshold you would set on each, using a 500 ms cold start budget.

15g. When not to use this

A cross-platform interface framework.

A shared cross-platform core module.

An abstraction over platform background scheduling.

A single unified permission facade.

Module 16. Security and privacy

Time: 50 to 60 minutes reading, 35 to 45 minutes practice.

The client runs on hardware the attacker may own, in a process they can inspect, on a network they may control. Every good client security answer starts by saying which attacker it is defending against, because the controls that stop one do nothing against another.

16a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| CLIENT SECURITY, as proposed                                  |
|   refresh token stored in plain key-value preferences         |
|   access token lifetime 30 days                               |
|   TLS pinned to the leaf certificate of the api host          |
|   that leaf certificate is rotated every 90 days              |
|   feature gate: if device is not jailbroken, allow transfers  |
| Release facts                                                 |
|   store review takes 2 days                                   |
|   update adoption 50 percent in 7 days, 90 percent in 30 days |
|   5,000,000 installed users                                   |
+---------------------------------------------------------------+
Caption: five client security choices, plus the release facts that
turn one of them into an outage.

Question. Compute how many users lose all access at the next certificate rotation even if you plan perfectly, and separately name what the jailbreak gate actually prevents.

Start with the threat model, because it decides everything else.

The row that changes an interview is the sixth. Say plainly that the client is untrusted, that every rule the business depends on is enforced server side, and that client-side checks exist to improve the experience of honest users and to raise the cost for casual attackers. That single framing separates a security answer from a list of features.

Secure storage, and what each tier resists.

The design rule that follows: the sensitivity of the data decides the tier, and the tier decides the failure you accept. Write both down. "Refresh token, in the hardware key store, device-only, so a stolen backup is useless and a stolen unlocked phone is not" is a complete sentence with a stated residual risk.

Token lifetimes, derived rather than picked. A stolen access token is usable until it expires, so the expected exposure from a single theft is roughly half the lifetime. Choose the lifetime from the value at risk per unit time:

The refresh token is the long-lived secret, so it gets the strongest storage and the strictest handling:

• Rotate on every use, so a refresh token is single use.
• Detect reuse. If a rotated token is presented twice, the family is compromised. Revoke every descendant and force re-authentication.
• Bind to the device where the platform allows it, so a stolen token cannot be replayed from elsewhere.
• Clear on logout, on account switch, and on detected compromise.

Pinning, done in a way that cannot brick your app. Five rules, each of which prevents a specific incident:

There is one more, and it is the detail that marks a senior answer: the kill switch for pinning cannot be delivered over the pinned connection. If pinning breaks, that channel is exactly what is unavailable. Fetch the pin configuration from a separate host with its own pin set, or sign the configuration and allow it to arrive through the push payload, which travels over the platform's connection rather than yours.

Permission models compared, at the level that changes a design.

The prompt policy that produces the best outcome.

• Ask at the moment the user is trying to do the thing that needs it, never on first launch. A prompt at launch has no context, so the rational answer is no.
• Show a pre-prompt of your own first, explaining the value and offering a way out. This costs you nothing (a user who declines your screen was going to decline the system prompt) and it preserves the one system prompt you get.
• Instrument three numbers: prompt shown, granted, and feature completed. The third is the one that matters, because a high grant rate on a feature nobody finishes is not a win.
• Test the denial path as a primary path, not as an error.

Denial fallbacks, so the feature degrades instead of dying.

Tamper resistance, priced honestly. Client-side integrity checks raise the cost of attack; they do not prevent it. Budget effort by what the attacker gains:

Privacy as design, not as a policy document.

• Minimise: every field you do not send is a field that cannot leak, cannot be subpoenaed, and cannot be mis-retained.
• Process on device where you can, and say what that costs (battery, model size, and a slower path to changing the logic).
• Redact by construction: a logger that refuses to accept token or credential types is better than a review that hopes nobody logged one.
• Watch the accidental channels: clipboard contents, screenshots in the task switcher, keyboard caches on sensitive fields, and crash reports containing request bodies.
• Retention: decide how long each on-device store keeps data and enforce it in code, because "until the user clears it" is not a retention policy.

+---------------------------------------------------------------+
| WHAT THE ATTACKER CONTROLS                                    |
+-----------------+-----------------+-------------------------+
| THE NETWORK     | THE DEVICE      | YOUR APP PROCESS        |
| use TLS, pin    | key store,      | assume total control    |
| the public key, | device-only     | enforce server side,    |
| ship 2 pins     | keys, auth gate | verify attestation      |
+-----------------+-----------------+-------------------------+
        |                 |                     |
        v                 v                     v
+---------------------------------------------------------------+
| WHAT THE SERVER MUST STILL ENFORCE ALONE                      |
| limits, authorisation, anomaly detection, step-up auth        |
+---------------------------------------------------------------+
Caption: three attacker positions with the control that answers
each, and the row that no client-side control can substitute for.

16d. Worked example

The prompt. "Design the security posture for a banking client: storage, tokens, transport, and what happens on a compromised device."

Inputs stated first:

Block A. Purpose: decide what the client can enforce at all

I split every rule into "client can enforce" and "server must enforce", before designing a single control:

I say the framing sentence out loud: the client's security job is to protect the honest user's data on the device and to avoid handing an attacker anything useful, while every rule the bank depends on is enforced somewhere the attacker cannot reach.

The error most readers make here. Presenting client controls as the security design. An interviewer hearing "we detect jailbreak and obfuscate the binary" with no server-side story concludes the candidate has not thought about who the attacker is.

Block B. Purpose: set token lifetimes from the value at risk

Reuse detection is the mechanism that makes 30 days acceptable: because each refresh token is single use, a second presentation of the same token means either a race or a theft. The server revokes the entire token family and forces re-authentication. I would tune for a small number of false positives from retries rather than tolerate a silent compromise, and I would make the client handle a forced re-authentication gracefully because it will happen.

The error most readers make here. Persisting the access token "so the app opens faster". It saves one request, adds a persistent copy of a credential, and undoes the entire reason for a short lifetime.

Block C. Purpose: choose storage tiers and the authentication gate

I state the residual risk explicitly, because a security design without one is incomplete: with an unlocked phone, an attacker sees balances and payees. They cannot transfer, because that needs a step-up authentication bound to the hardware key. That is the line I have deliberately drawn, and I would confirm it against the bank's risk appetite.

The error most readers make here. Gating everything behind biometric authentication. Requiring authentication to see a balance trains users to authenticate constantly, which makes the prompt meaningless at the moment it matters. Gate the action, not the view.

Block D. Purpose: pin transport without creating an outage

Now the arithmetic that justifies it. Under the artefact's original design, a rotation lockout hits 10 percent of 5,000,000 users, so 500,000 people, even with a 30 day lead. Under this design, leaf rotation is invisible because the intermediate key is unchanged, and even an intermediate change is covered by the backup pin without any app update at all.

The error most readers make here. Treating pinning as a security control with no availability cost. Pinning is the one client-side control that can take your entire user base offline, and it must be designed with the failure mode in front of you.

Block E. Purpose: handle the compromised device and the privacy surface

Privacy decisions, stated as design choices rather than compliance text:

• Do not send device identifiers you do not use. Every identifier collected is an obligation.
• Redact request and response bodies from crash reports by default, and allowlist specific fields rather than denylisting sensitive ones.
• Set a retention policy per on-device store: transactions cached for an assumed 90 days, then trimmed, because the app is not an archive.

The error most readers make here. Blocking the app on a failed integrity check. It converts a probabilistic signal into a binary outcome, locks out legitimate users on unusual devices, and gives an attacker a clear oracle to test their bypass against. Feed the signal into a risk score instead.

16e. Fade the scaffold

Fade 1: a health app storing records offline. Records are highly sensitive, must be readable offline, and are shared with a clinician through a code. Same five-block shape, last block blank.

• Block A, what the client can enforce: the client protects data at rest and in the interface. Access control over who may read a record is enforced server side, and the sharing code is validated there, never locally.
• Block B, token lifetimes: access token of an assumed 30 minutes, since the value at risk is disclosure rather than money movement and clinicians use the app in sessions. Refresh token 14 days, rotated, in the hardware key store, requiring user authentication because the data is sensitive enough to justify the friction.
• Block C, storage tiers: the record database is encrypted with a key store key gated on user authentication, and the key is released for the session so offline reading works after one unlock. Attachments are stored as encrypted files, excluded from backup.
• Block D, pinning: public key pinning on the intermediate, two pins, expiry, report-only first. Identical to the banking case, because the transport threat does not vary by industry.
• Block E, compromised device and privacy surface: you write this block.

Fade 2: a consumer app adding a peer-to-peer money transfer feature. Last two blocks blank.

• Block A, what the client can enforce: nothing about the money. Every limit, every eligibility rule and every fraud decision is server side. The client contributes signals and a good experience.
• Block B, token lifetimes: the existing social session stays long lived, but the transfer feature gets a separate step-up token, minutes long, obtained through a re-authentication that is bound to hardware.
• Block C, storage tiers: you write this block.
• Block D, pinning and transport: you write this block.

16f. Check yourself

Q1. Your app pins correctly, and support reports that users on a particular corporate network cannot sign in. Give the mechanism, and say what your report-only rollout would have told you.

Q2. A product manager asks for a "remember me" feature that keeps users signed in for a year. Give your counter-proposal with the specific token design and one number that shows the exposure you removed.

16g. When not to use this

Certificate or public key pinning.

Biometric or passcode gating on app open.

Root and jailbreak detection.

On-device encryption of the whole local database.

Module 17. Release engineering

Time: 50 to 60 minutes reading, 40 to 50 minutes practice.

You cannot patch a client. Whatever ships is what runs, on devices you do not control, for months. Everything in this module exists to buy back the control you lost at submission: flags to change behaviour without a build, deterministic bucketing so experiments mean something, durable telemetry so you can see what happened, and a rollout ladder that limits how many people a mistake reaches.

17a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| EXPERIMENT SETUP, as configured                               |
|   Remote config fetched at launch, blocking up to 5 s         |
|   Variant chosen server side, per request, from a random      |
|   number                                                      |
|   Exposure logged when the config fetch completes             |
|   Telemetry posted fire and forget, dropped when offline      |
|   Rollout was 50 percent, raised to 70 percent on day 3       |
| Facts                                                         |
|   Cold start budget 500 ms                                    |
|   Only 20 percent of users reach the screen the flag changes  |
+---------------------------------------------------------------+
Caption: an experiment configuration with four independent defects,
plus the two facts that let you size two of them.

Question. Name three separate reasons the experiment result is unreadable, and compute the cold start damage.

Four kinds of flag, four lifetimes, four owners.

Flag hygiene, with the arithmetic that forces it. Assume a team adds 8 flags a quarter and removes 2. After two years that is 48 stale flags. Nobody tests that surface, because the combinations are astronomically many, and the honest practice is to test the default path and the fully-on path only. That is exactly why every flag needs an owner, an expiry date and an automatic reminder, and why a flag past expiry should fail a build rather than generate a ticket nobody reads.

The evaluation contract, which fixes the startup defect.

• Flags are evaluated locally, from a cached snapshot on disk, in microseconds.
• Every flag has a compiled-in default, used when no snapshot exists. The first launch after install must be correct with no network at all.
• The snapshot is refreshed asynchronously, never on the startup critical path.
• Refreshed values apply on the next launch by default. Only flags explicitly declared live-safe apply mid-session, because a variant that changes under the user's fingers breaks both the experience and the experiment.

Deterministic bucketing, in two stages. The bucketing function is:

+-------------------------------------------------------------+
| bucket(salt, unit) = hash(salt + ":" + unit) mod 10000       |
|                                                             |
| eligible if  bucket(experiment_salt, unit) < rollout x 100  |
| variant   if bucket(variant_salt, unit) < 5000 then A else B|
+-------------------------------------------------------------+
Caption: two independent hashes. The first decides who is in the
experiment, the second decides which arm, so raising the rollout
adds users without moving anyone already assigned.

Why two stages rather than one is the point of the design. With a single hash, raising the rollout from 50 to 70 percent shifts the boundary and can move users across arms. With two, eligibility grows monotonically and every already-eligible user keeps their arm forever, which is what makes a ramp safe mid-experiment.

The salt matters for a second reason: a different salt per experiment makes the buckets independent, so a user who was in the treatment of experiment one is not systematically in the treatment of experiment two. Reusing one salt across experiments correlates them and quietly ruins both.

Choosing the unit.

The login transition is the trap. A user bucketed on install identifier before sign-in and on account identifier afterwards can change arm mid-session. Two defensible fixes: analyse only post-login exposures for account-level experiments, or record the install-to-account link and keep the original assignment for the life of the experiment. Pick one and say which.

Detecting a broken split before reading any metric. A sample ratio mismatch means the observed split differs from the intended one, and it invalidates everything downstream. Derive the tolerance:

• Total exposed users: 200,000, intended 50/50, so expected 100,000 per arm
• Standard deviation of a count under a fair split: sqrt(n x 0.25) = sqrt(50,000) = 223.6
• Observed 101,200 versus 98,800: the deviation is 1,200, which is 1,200 / 223.6 = 5.4 standard deviations

Five standard deviations is not a fluctuation, it is a bug: a filter applied to one arm, a crash that removes users from one arm before exposure, or a bucketing mistake. The operating rule is to check this first and refuse to read the metrics if it fails.

Exposure logging, stated precisely. Log an exposure at the line where the flag value changes what the user gets, once per session, carrying the flag name, the variant, and the configuration version. Not at fetch, not at app start, and not on every evaluation. The dilution arithmetic in 17a is the whole justification, and it is the single most common experimentation bug in mobile clients.

Offline-durable telemetry, sized.

Four properties the queue needs, each preventing a specific failure:

• Durable and transactional: an event written and the app killed a millisecond later must still be there. Otherwise your crash-adjacent events are the ones you lose.
• Deduplicated by an event identifier generated at creation. Retries after an ambiguous timeout are normal, and double counting corrupts every rate.
• Priority classes with a drop policy: when the cap is reached, drop the lowest priority oldest first, and never drop crash, stability or billing events.
• Clock corrected: send the device's wall clock, the device's monotonic uptime, and the age of each event at send time, so the server can reconstruct ordering even when the device clock is wrong or was changed while offline.

Staged rollout, with the hold time derived rather than guessed. The question a stage answers is: has this build made stability worse. Size it.

• Baseline crash-free sessions: 99.6 percent, so p1 = 0.004
• A regression worth catching: 99.3 percent, so p2 = 0.007
• Sample per arm at conventional power: (1.96 + 0.84) squared x (p1(1 - p1) + p2(1 - p2)) / (p2 - p1) squared
• = 7.84 x (0.003984 + 0.006951) / 0.000009
• = 7.84 x 0.010935 / 0.000009 = 9,525 sessions

So roughly 9,500 sessions in the new build are needed to see a 0.3 point crash regression. At 1,000,000 daily sessions:

The holds beyond the detection time exist for a different reason, and saying so is what makes the ladder defensible: usage patterns vary by hour and by day, and a bug that only appears on the commute or on a weekend needs a clock, not a sample size.

Forced update and version skew.

Size the hard block before proposing it. At 90 percent adoption in 30 days, a hard block 30 days after release still locks out 10 percent of installed users, and those users are disproportionately on old devices or constrained networks. The server contract's compatibility window is therefore a business decision with a number attached: supporting one more version costs you a code path, and dropping it costs you a measurable share of users.

Release health, and what to alert on.

Compare against the previous release rather than an absolute target, because absolute crash rates vary with device mix and season, and a relative comparison at the same rollout stage controls for both.

17d. Worked example

The prompt. "Design the flag, experiment and telemetry stack for a 1 million daily active user app."

Inputs first:

Block A. Purpose: fix the evaluation path before designing anything clever

The startup rule comes first because everything else depends on it: flags evaluate from a local snapshot, synchronously, in microseconds, with compiled defaults. The network refresh happens after the first frame, on a background thread, and applies at the next launch unless the flag is declared live-safe.

I say the consequence out loud: the app's first launch after install must be correct with the defaults compiled into the binary, which means every flag's default is a product decision made at build time, not an accident.

The error most readers make here. Blocking on a config fetch "just for a moment" to avoid a flash of the wrong experience. The moment is a network round trip, so it is 300 ms at the median and a timeout at the tail, and it turns a configuration system into the largest single contributor to cold start.

Block B. Purpose: bucket so a ramp cannot corrupt the experiment

Two hashes, as in the diagram above: one for eligibility against the rollout percentage, one for the arm. Unit is the account identifier for anything measured per person, and the install identifier for onboarding experiments that happen before sign-in.

I check the ramp property explicitly, because that is what the artefact got wrong. Going from 50 to 70 percent changes only the eligibility test, and the eligibility hash for a given user is fixed, so every user who was already in stays in with the same arm. The added 20 percent are new, and I flag them as a separate cohort for analysis rather than pooling them.

Then the guard: a sample ratio mismatch check runs before any metric is read. At 200,000 exposed users the standard deviation of an arm count is 223.6, so I set the automated check to refuse the analysis at more than 4 standard deviations, which is about a 900 user imbalance, and to page the owner rather than silently reporting a result.

The error most readers make here. Bucketing on a session or a device where the analysis is per person. The arithmetic then treats one heavy user's twenty sessions as twenty independent observations, which understates variance and manufactures significant results out of nothing.

Block C. Purpose: make telemetry survive the conditions you are measuring

The exposure event is special and gets the highest non-crash priority, because an experiment with missing exposures is not an experiment.

The error most readers make here. Holding the queue in memory and writing it on backgrounding. Process death does not call your backgrounding hook reliably, so the sessions that end in a kill lose all their events, and those are exactly the sessions where something went wrong.

Block D. Purpose: derive the rollout ladder from detection power

Using the derivation above, 9,525 sessions in the new build detects a 0.3 point crash regression:

Halt criteria are written before the rollout starts, not decided during it:

• Crash-free sessions below the previous release by more than 0.3 points at any stage: halt and roll back.
• Hang or not-responding rate up at all: halt, because these are main-thread regressions and they get worse with slower devices, which arrive later in the rollout.
• A single new crash signature above an assumed 0.05 percent of sessions: halt.
• Support contact rate up by an assumed 20 percent: investigate before advancing.

The error most readers make here. Advancing on a schedule instead of on a signal. A rollout that moves to the next stage every 12 hours regardless of what the numbers say is a countdown timer, not a safety mechanism.

Block E. Purpose: decide what you do when the flag is not enough

Two mechanisms, with the boundary between them stated:

Sizing the last row honestly: a hard block 30 days after release still strands 10 percent of installs, which at 1,000,000 daily actives is 100,000 people. That number belongs in the proposal, because it converts an engineering convenience into a business decision.

The error most readers make here. Building a kill switch and never testing it. A switch that has not been flipped in production is a switch that has a 50 percent chance of not working during the incident that needs it, and the incident is the worst time to discover the flag never reached the evaluation path.

17e. Fade the scaffold

Fade 1: a pricing experiment on a subscription paywall. Three price points, revenue is the metric, and the finance team needs the result to be defensible. Same five-block shape, last block blank.

• Block A, evaluation path: prices come from the cached snapshot with compiled defaults, and the price shown must never change mid-session. This flag is not live-safe, because a price that changes while a user is deciding is both a bad experience and a possible compliance problem.
• Block B, bucketing: account identifier where available, install identifier before sign-in, with pre-login exposures excluded from the revenue analysis. A dedicated salt, because correlating price with any other experiment would make both unreadable.
• Block C, telemetry: paywall view, price shown, purchase attempted and purchase completed all become high priority durable events. Purchase events are never dropped, and they are reconciled against the store's server notifications rather than trusted from the client.
• Block D, rollout: this is an experiment rather than a release, so the ladder is about revenue risk rather than crash detection. Start at an assumed 5 percent and size the duration by the metric's variance, not by crash power, because revenue per user is far noisier than a crash rate.
• Block E, what you do when the flag is not enough: you write this block.

Fade 2: a feature flag system delivered as an SDK to third-party apps. Host apps embed it, and you cannot see their code. Last two blocks blank.

• Block A, evaluation path: identical rules, enforced harder. Evaluation is synchronous from a local snapshot with host-supplied defaults, and the SDK must never block the host's startup. If the host has no snapshot, evaluation returns the default the host passed at the call site, which means the host's code is correct even if your SDK never initialises.
• Block B, bucketing: the SDK cannot choose the unit, because only the host has a notion of a user. The host supplies the unit identifier, and the SDK provides the hash and the two-stage scheme, plus a documented guarantee that the same unit and salt always produce the same bucket in every SDK version.
• Block C, telemetry: you write this block.
• Block D, rollout: you write this block.

17f. Check yourself

Q1. Your experiment shows a 2 percent lift with a comfortable significance level, and then you notice the treatment arm has 3 percent more users than the control. State what you do and why, with the arithmetic for 200,000 exposed users.

Q2. A teammate wants to apply remote config changes immediately rather than at next launch, because "waiting is a worse experience". Give the two categories of flag where they are right and the general rule you would write down.

17g. When not to use this

A remote configuration system.

Client-side experimentation infrastructure.

A staged rollout ladder with derived holds.

A hard forced update.

Module 18. Library and SDK design

Time: 45 to 55 minutes reading, 35 to 45 minutes practice.

Component-scale prompts appear in mobile rounds under names like "design an image loading library", and they reward preparation that an app-shaped answer does not give you. The shift is that your code runs inside someone else's process, on their startup budget, their battery, their crash rate and their support queue, and you cannot see their code. Every rule below follows from that.

18a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| PROPOSED SDK SURFACE                                          |
|   Analytics.init(context, apiKey)   static, called at start   |
|      opens a database             8 ms                        |
|      reads a config file          4 ms                        |
|      starts a network request     async                       |
|   Analytics.track(name)             returns void              |
|   Analytics.setListener(l)          l is invoked on an        |
|                                     internal worker thread    |
|   The public Event type exposes a third-party JSON type       |
| Host facts                                                    |
|   Host cold start budget 500 ms, currently at 430 ms          |
|   Storage p99 latency is about 10x the median                 |
+---------------------------------------------------------------+
Caption: a proposed public surface with its startup cost, plus the
two host facts that decide whether it is acceptable.

Question. Compute the p99 startup contribution, and name the two support tickets that arrive in the first week.

The five budgets a host lends you, and what to ask for.

Public API rules, each preventing a named failure.

The threading contract, written as a table in your documentation.

Two rules to state out loud: nothing in the public surface blocks the calling thread, and no callback arrives on a thread the caller did not choose. Providing a default of "main thread" and an option to supply an executor covers both the casual integrator and the sophisticated one.

The error model, in three classes.

The invariant that summarises all three: an SDK may fail, and may say it failed, but must never take the host process down. A host that has been crashed once by a vendor SDK removes it, and no amount of feature work wins them back.

Extensibility: exactly three seams, and the reason to stop there.

Every additional seam is a permanent commitment: it appears in the public surface, it constrains your internals forever, and it must keep working across every future version. Say no by default and add a seam when two separate hosts have asked for the same one.

Initialisation cost, designed down to nothing.

• At configure, store the options and return. Do no disk or network work.
• Schedule the real setup (open storage, load the queue, read config) on a background thread after the host's first frame, or lazily on first use, whichever comes first.
• Buffer calls that arrive before setup completes in a small bounded in-memory list, an assumed 100 entries, then hand them to the queue once it exists.
• Measure the result the way a host would: cold start with and without the SDK, on a mid-tier device, reported at p50 and p90.

That takes the artefact's 12 ms median and 120 ms tail on the main thread to effectively zero, and the cost is a few hundred bytes of buffer.

Binary size, which hosts really do audit.

Versioning and deprecation, as a written contract.

• Semantic versioning applies to the public surface, not to your internals, and that distinction must be documented or every patch release becomes a debate.
• Binary compatibility matters where hosts consume prebuilt artefacts, and it is broken by changes that look harmless in source, such as adding a parameter with a default or changing a type in a signature.
• Deprecation runs on a clock: mark deprecated with a replacement named in the message, keep it working for an assumed two minor versions or six months whichever is longer, then remove in a major version.
• Never expose a third-party type. If you must interoperate, provide a small adapter module that hosts opt into.

Surviving a hostile host. Your code will run under all of these, and each one should be a test:

Diagnosability inside a host you cannot debug. Provide a diagnostics() call returning a snapshot: SDK version, initialisation state, queue depth, oldest queued event age, last error, and last successful send. Add a verbose logging toggle and an in-memory ring buffer of the last 100 operations. This turns a week of email into one screenshot, and it is the single highest-leverage feature for support cost.

+---------------------------------------------------------------+
| PUBLIC SURFACE   configure, track, flush, identity, diagnose  |
| no blocking, no third-party types, caller chooses the thread  |
+-------------------------------+-------------------------------+
                                |
                                v
+---------------------------------------------------------------+
| DEFERRED CORE    starts after first frame or on first use     |
| bounded buffer > durable queue > batcher > transport seam     |
+-------------------------------+-------------------------------+
                                |
        +-----------------------+-----------------------+
        v                       v                       v
+----------------+   +--------------------+   +------------------+
| STORAGE SEAM   |   | CLOCK AND LOGGER   |   | HOST TRANSPORT   |
| location, key  |   | injectable, fake   |   | optional, host   |
| supplied       |   | in tests           |   | client if given  |
+----------------+   +--------------------+   +------------------+
Caption: a thin non-blocking public surface over a core that starts
late, with exactly three replaceable seams and nothing else.

18d. Worked example

The prompt. "Design the public API for an analytics SDK that third-party apps will embed."

Inputs first:

Block A. Purpose: write the surface backwards from the caller's worst day

I start from the integration failures I expect and design the surface so each one is impossible:

The resulting surface is five calls: configure, track, identity, flush, diagnostics. I say the number out loud, because a small surface is a design claim rather than an omission, and it is the thing a reviewer can check.

The error most readers make here. Designing the surface from the feature list. The feature list produces one method per capability and a static setter for every option. Designing from the caller's failures produces a surface that is small because each addition has to defend itself.

Block B. Purpose: state the threading contract as part of the API

Documented in a table shipped with the SDK, and enforced in code:

The serial queue is the whole concurrency design, and it is deliberately boring. A single owner thread for mutable state removes an entire class of bugs that would otherwise be reported as flakiness by hosts you cannot debug.

The error most readers make here. Offering a synchronous variant "for convenience". Every synchronous method in an SDK eventually gets called on the main thread by a host under deadline pressure, and then your library owns their application-not-responding rate.

Block C. Purpose: define what fails, how it is visible, and what never happens

The dropped-events figure is worth its own sentence: sending the count of what you dropped, with the next successful batch, means the host's analysis can tell the difference between "nothing happened" and "we lost the data". Silent loss makes every downstream number untrustworthy.

The error most readers make here. Rethrowing an internal error to be "transparent". Transparency for an SDK means a value the caller can inspect, not an exception crossing into code that has no idea what to do with it.

Block D. Purpose: budget startup, memory and binary size, then measure

I state the trade I made: hand-writing the encoder costs me a day and some ongoing care, and it buys the largest single line item in the size budget. That is a defensible engineering trade for a library and a bad one for an app, and the difference is that a library's cost is multiplied by every host.

The error most readers make here. Measuring size and startup on the SDK in isolation. The number that matters is the delta in a real host application with its own dependencies, because dependency overlap can make your contribution smaller or much larger than it looks alone.

Block E. Purpose: write the versioning contract before the first release

The server compatibility row is the one that is easiest to forget, and it is the largest long-term cost of shipping an SDK. Hosts upgrade slowly, some never, so your ingestion path carries every payload shape you have ever released. Deciding the window explicitly, and instrumenting the share of traffic from each version, is how you eventually retire one.

The error most readers make here. Treating a major version bump as a way to clean up. Hosts do not upgrade major versions on your schedule, so a major version that drops old behaviour splits your user base into two populations you must both support, which is more work than the cleanup saved.

18e. Fade the scaffold

Fade 1: an image loading library. Hosts pass a URL and a view, and expect a correctly sized image with caching and cancellation. Same five-block shape, last block blank.

• Block A, surface backwards from failures: the feared failures are memory kills, wrong images appearing in recycled views, and jank. So the surface takes the target view (to derive size and to key cancellation), the request is cancelled automatically when the view is recycled or detached, and decoding always targets the view's measured size rather than the source dimensions.
• Block B, threading contract: load is main-safe and returns immediately. Decode happens on a bounded pool. The completion callback is delivered on the main thread by default, because it will be used to update a view.
• Block C, error model: a missing image is an expected condition and produces a placeholder plus an inspectable result, never an exception. A decode failure disables that entry rather than the library.
• Block D, budgets: memory cache capped in bytes at a fraction of the host's heap that the host can configure, disk cache capped and in the cache directory, zero background work, and no general purpose dependencies.
• Block E, versioning contract: you write this block.

Fade 2: a feature flag SDK for third-party hosts. Evaluation must work offline and must never block the host. Last two blocks blank.

• Block A, surface backwards from failures: the feared failures are a blocked startup, a wrong value before the snapshot loads, and inconsistent values within a session. So evaluation is synchronous against a local snapshot, every call site passes its own default, and values are frozen for the session unless the flag is declared live-safe.
• Block B, threading contract: evaluation is main-safe and lock-free against an immutable snapshot swapped atomically. Refresh happens on a background thread. Change callbacks arrive on a caller-supplied executor.
• Block C, error model: you write this block.
• Block D, budgets: you write this block.

18f. Check yourself

Q1. Your SDK exposes Result<Void, AnalyticsError> from track. A host reports that their code is now cluttered with error handling for a call they do not care about. Give your two options and say which you would pick and why.

Q2. A host asks you to add an interface so they can supply their own event serialisation. Give the questions you would ask and the criterion you would use to decide.

18g. When not to use this

Shipping an SDK at all.

An extensibility seam.

Your own thread pool inside an SDK.

Automatic instrumentation that captures screens and interactions.

Module 19. Interview mechanics

Time: 35 to 45 minutes reading, 30 to 40 minutes practice.

The hub page owns the general delivery clock for system design rounds. This module is the client-specific version: what to draw, in what order, what to leave off, and the exact sentence that turns "I am running out of time" from a failure into a demonstration of judgement.

19a. Predict first

Read this artefact and commit to an answer before continuing.

+---------------------------------------------------------------+
| TRANSCRIPT TIMELINE, 45 minute mobile round                   |
|   00 to 18   clarifying questions, fourteen of them           |
|   18 to 38   one diagram drawn, 22 boxes, no numbers anywhere |
|   38 to 43   interviewer asks about offline behaviour.        |
|              Candidate answers "we would cache it"            |
|   43 to 45   candidate asks their questions                   |
| The score sheet has five dimensions                           |
|   framing, budgets, architecture, depth, communication        |
+---------------------------------------------------------------+
Caption: how forty-five minutes were actually spent, next to the
five things the interviewer has to write a score against.

Question. Name the dimension that was already unrecoverable at minute 25, say why, and explain how the diagram made it worse rather than better.

The client round's minute budget, and why it differs from a backend one. A backend round spends heavily on capacity estimation and storage topology. A client round spends that time on state, lifecycle and constraint budgets, because those are where client systems actually fail.

The drawing order, which is the highest-leverage habit in this module. Draw in this sequence, narrating as you go, and stop at eight boxes.

What to leave off, deliberately and out loud: dependency injection, class names, the backend's internal services, analytics plumbing, and any box whose only role is to show that you have heard of it.

The opening, four sentences.

• "I read this as a client design problem: the interesting parts are state, offline behaviour and the budgets, and I will treat the server as a contract we can negotiate."
• "I will spend about five minutes on requirements and numbers, ten on the architecture, then take one area deep, and leave the last five for failure modes and what I skipped."
• "Two clarifying questions that change the design, then I will start drawing."
• "Stop me if you want the time spent differently."

The fourth sentence is the one people leave out and it is the cheapest point on the page: it makes the plan negotiable, which turns any later redirection into collaboration rather than correction.

Checkpoints, one sentence each, roughly every ten minutes.

The four numbers to state in the first five minutes. All four come from earlier modules and none requires a calculator:

Stating even two of these changes what the rest of the round can be about. A client described with no quantities in it cannot have a breaking point, and without a breaking point there is nothing for a v1 to fix.

Descoping at minute 25, which is a skill rather than an apology. The rule: at minute 25 of a 45 minute round, count the areas you still want to cover. If it is more than one, you are over-scoped and you say so.