Display a dynamic uptime claim without hurting Core Web Vitals
Tests separation of data and rendering paths for dynamic claims. Pre-compute the metric in a background job, cache at the edge, and inject via SSR to avoid blocking the main thread. A red flag is synchronous DB lookups or CSR that delays interactivity.
What's really being asked
This question evaluates whether you can keep dynamic data from polluting the critical rendering path. Interviewers want to see that you understand the difference between a data pipeline and a presentation layer, and that you know how to use caching and server-side rendering to protect Core Web Vitals like INP and LCP. The uptime claim is a proxy for any slowly-changing metric that must be accurate but cannot be allowed to block the main thread or trigger layout shifts.
The full answer
First, an asynchronous calculation layer. You should propose a background worker or cron job that reads uptime logs from the past month, computes the 99.9 percent SLA, and writes the result to a durable store. Second, a caching and serving strategy. The computed value should live in a low-latency cache such as Redis or an edge key-value store with a TTL of a few minutes, and it should be served through server-side rendering or an edge function so the browser receives the number in the initial HTML. Third, resilience and accuracy. Mention stale-while-revalidate or a fallback cached value so that if the latest calculation fails, the page still shows a recent valid number rather than an error or a loading spinner. Fourth, Web Vitals guardrails. Avoid client-side rendering of the claim because it requires shipping JavaScript that competes for the main thread; instead, send static HTML and optionally hydrate around it without rehydrating the metric itself.
The mistakes people make
Proposing to query a raw events database directly from the homepage request path. This introduces unpredictable latency and can spike TTFB. Suggesting a client-side fetch after the page loads, which hurts INP and can cause cumulative layout shift when the number finally appears. Ignoring cache invalidation or claiming the metric should be real-time to the second; uptime is inherently retrospective, so sub-minute freshness is unnecessary. Failing to mention a fallback when the cache expires or the worker stalls.
What usually comes next
How would you handle a last-minute outage that changes the monthly number right before the month ends? How do you prevent a thundering herd if the cache expires during a traffic spike? What would you do if the uptime logs live in a data warehouse with slow query times? How would you verify the accuracy of the displayed claim against the raw logs?
A concrete example
Imagine a Node service running on a schedule every five minutes. It queries a time-series database for the past thirty days of health-check results, filters out planned maintenance windows, and writes 99.92 to a Redis key homepage.uptime_sla with a ten-minute TTL. A Next.js edge function reads this key at request time and embeds the string directly into the server-rendered headline. If Redis is unreachable, the edge function serves the value from a stale-while-revalidate header cached at the CDN layer, ensuring the headline never blocks on a database and the main thread remains free for user interactions.
Interview question
Which architecture best displays a dynamic uptime SLA while protecting Core Web Vitals on a high-traffic homepage?
- a.Pre-compute the SLA in a scheduled worker, cache it, and inject the value via server-side renderingCorrect
- b.Compute the SLA on-demand in an edge function that queries the raw logs database directly
- c.Fetch the SLA from a browser API call after hydration to guarantee the latest value
- d.Read the cached SLA from Redis on the client after the page loads to avoid server-side data fetching
Why? this is the answer
Pre-computing and caching the metric lets the server embed it in the initial HTML without blocking the main thread or causing layout shifts. Reading a cached value client-side still requires JavaScript execution and a network round-trip, which hurts INP and risks CLS.
Just read this? Test yourself on what you have been reading.
Read the original → web.dev
- #system design
- #caching
- #core web vitals
- #server-side rendering
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on system design — each one lists the topics its interview covers.
See open roles