Partial Screen Response
also called Degradable Screen Region, Per Region Response State
A screen payload whose regions each declare their own state, so an aggregating layer can answer within its deadline with one degraded region instead of failing a screen whose other regions were ready.
A home screen aggregates seven services. Six answer in about 60 ms. The recommendations service is having a bad afternoon and answers at 2.4 s at the 99th percentile, against the backend-for-frontend's 800 ms budget.
Today it returns a 500, and the user gets an error page for a screen whose six working regions would have been perfectly useful. One struggling dependency has become a total outage for everybody, for as long as the bad afternoon lasts.
Why it matters
An all-or-nothing response makes a screen's availability the product of its dependencies' availabilities. Seven dependencies at 99.9% each give 0.999^7 ≈ 99.3% — roughly five hours of unavailability a month — and it gets worse with every region a product manager adds.
Declaring regions individually turns that multiplication into a sum of partial outcomes: the screen is available whenever its required regions are. Seven dependencies with one required region give the screen that dependency's availability, not the product of all seven — the largest availability lever on an aggregated screen, and it costs a schema change.
Implementation patterns
- Carry state per region, not a null.
{ data, state, staleAt }, where state is ok, degraded or unavailable. A null cannot distinguish "no recommendations" from "we could not ask". - Classify regions once, with the product owner. Required means the screen is meaningless without it, and there should be one or two. Everything else is optional, in writing, before the incident.
- Allocate the deadline explicitly. Optional regions get a shorter per-region deadline — say 250 ms of an 800 ms budget — so one slow optional call cannot consume the screen's time.
- Serve stale for optional regions. A list from ten minutes ago beats an empty shelf, and
staleAtlets the interface say how old it is. - Design and test every declared state, with reserved height and real copy. An undesigned state renders as a collapsed div and a layout shift.
Industry example
The archetype is a large consumer home screen under a demand spike — a large Indian e-commerce app at festival-sale peak — where the personalised recommendation shelf is the heaviest and least essential region on the page, and the first thing shed. Products that survive these events in production share one property: the degradation was decided and implemented months earlier.
The pattern is the client-side half of graceful degradation, written down separately because degradation
designed only on the server produces a client that renders null as an empty page.
Failure scenarios
- Null conflated with empty. The client shows "no results" during an outage and the user concludes the product is broken.
- An optional region that was secretly required. The buy button sits in a region marked optional, so the screen renders with no way to purchase and the revenue graph is the only alert.
- No per-region deadline. The aggregator waits for the slowest optional call, so the pattern is in the schema and not in the behaviour.
- The metric trap. Screen-level success stays at 99.9% while a region has been unavailable for a week, because partial success counts as success. Per-region reporting is the fix.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Per-region states | screen availability set by required regions only, graceful behaviour under a slow dependency | a richer schema, a designed and tested state per region, per-region observability |
| All-or-nothing responses | one client code path, trivially correct when everything works | availability is the product of every dependency, and one slow service is a total outage |
The cost is mostly on the client and it is real: every declared state is a design, a translation and a test. A team that ships the schema without the designs has built a page that looks complete while missing a shelf, which nobody reports.
When not to use it
A screen with a single data source has nothing to partition. More importantly, a screen where every region is genuinely required must fail rather than render partially: a payment confirmation, a legal disclosure, a medical record summary. A missing region there is not degradation, it is misinformation.
The rule: use it only if you can name, design and test the degraded state for every optional region. Otherwise prefer failing cleanly, because an honest error beats a confident half-page.
Interview question
Q: "Your home screen aggregates seven services and returns a 500 whenever any of them is slow. Design the response contract that fixes it. Tell me who decides which regions are optional, what deadline each region gets, and how you would know a week later that a region had been down the whole time."
What a strong answer covers: per-region state rather than nullable fields; the availability arithmetic; per-region deadlines with cancellation; stale-serving for optional regions; the product owner as the decider of optionality, agreed in advance; and per-region metrics, because screen-level success rate hides this failure.
Quick check
Quiz: Seven dependencies at 99.9% back one all-or-nothing screen. What is its availability, and what changes it? — About 99.3%, roughly five hours a month; declaring regions optional makes it the availability of the required regions instead of the product of all seven.
Flashcard: Why is a null field not a degraded state? — It cannot distinguish "no data exists" from "we could not fetch it", so the client shows an empty state during an outage and the user blames the product.