Performance
Performance capstone: multiple-choice synthesis
Crux Cross-track synthesis MCQs — pick the dominant cost, the right layer to fix, and the verification step across profiling, hot paths, cache, GC, N+1, batching, and bundles.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitThe whole track collapses into one loop: profile, classify the dominant cost, fix it at the right layer, verify, enforce. Each question hands you a symptom that touches two or three units at once and asks for the first move a senior engineer makes.
Goal
Confirm you can run the cross-cutting decision the track was built for: refuse to guess, find the one cost that dominates, fix it where it actually lives, and prove the fix with numbers under the same load.
Quiz
Completed
A checkout page feels slow. A senior engineer is told the JSON serializer is 'obviously' the bottleneck. What do they do first, and why?
Heads-up Acting on a named suspect without measurement is exactly the failure the track opens with. If the serializer is 3% of wall time, even eliminating it entirely yields a 3% ceiling by Amdahl's law.
Heads-up A cache helps only if the dominant cost is recomputation or repeated I/O. Caching a page whose cost is one slow downstream call adds invalidation complexity for no win, and you still do not know where the time went.
Heads-up Replacing the runtime is the most expensive, lowest-information move possible before profiling. You would rewrite everything to chase a cost you have not located.
Quiz
Completed
A flame graph shows one function dominating CPU, and within it the time is spent in memory allocation and the subsequent GC. Where does the durable fix live?
Heads-up Deferring GC trades memory for fewer cycles and can push you toward OOM; it masks an allocation hotspot the profiler already located. The fix ladder eliminates allocation before it tunes the collector.
Heads-up The profile points at allocation, not at asymptotic growth. A lower-O structure that allocates per element can make GC pressure worse; match the fix to the cost shape the profiler shows.
Heads-up More workers multiply allocation rate and GC pressure on the same hot path; parallelising an allocation-bound function spreads the problem rather than removing it.
Quiz
Completed
A dashboard endpoint issues 1 fast query to list 50 orders, then 50 more queries to fetch each order's customer. Each query is 2 ms. Profiling the queries themselves shows nothing slow. What is the dominant cost and the right fix?
Heads-up An index shaves microseconds off queries that are already fast; it does not remove the 50 round-trips. The cost is fan-out, not per-query latency.
Heads-up Vertical scaling buys headroom for the same 51 round-trips; the structural waste of one-query-per-row remains and reappears at the next traffic level. Fix the access pattern, not the box.
Heads-up A cache can hide the symptom on warm hits but still pays N round-trips cold, adds invalidation, and leaves the N+1 pattern in the code to bite the next endpoint. Batch the access first.
Quiz
Completed
An ingestion service makes one network call per event with ~3 ms of fixed per-call overhead (connection, auth, serialization) and ~0.1 ms of useful work. Throughput is capped. Batching events into groups of 100 is proposed. What is the real tradeoff to state up front?
Heads-up Batching trades latency for throughput. The first event in a batch waits for the window; under low load the max-wait timer dominates. There is always a tail-latency charge to budget against the SLO.
Heads-up It is the reverse: batching pays most when fixed per-op overhead dominates the useful work, exactly this 3 ms vs 0.1 ms case. Large per-event work would dilute the fixed-cost amortization.
Heads-up Ingestion events are distinct writes, not repeated reads; there is nothing to cache. The fixed per-call overhead is amortized by batching, not by caching.
Quiz
Completed
A product page added a 280 KB (gzipped) date-picker library to ship one calendar widget. Lighthouse TTI regressed on mid-tier mobile. Server response time is unchanged. Where is the cost and how do you keep it from recurring?
Heads-up Faster delivery does not remove the parse/compile/execute cost those bytes impose on a weak CPU; TTI is gated by main-thread work, not just transfer time. Ship fewer bytes.
Heads-up The brief states server time is unchanged; the regression is entirely client-side JS execution. Optimising the backend addresses a cost that is not the dominant one here.
Heads-up Bundle bloat is paid by every visitor on every load and accretes one dependency at a time. Without a CI budget it ratchets up invisibly — the enforce step exists precisely to stop this.
Quiz
Completed
You shipped a fix, p99 looks better on your laptop, and the ticket is ready to close. What still has to be true before the work is actually done, per the track's loop?
Heads-up Local numbers omit production concurrency, data volume, cache state, and contention. A fix must be verified under representative load, or you are trusting the same intuition the track told you to distrust.
Heads-up Unverified and unenforced, a gain decays the moment someone adds the next feature. The loop ends in verify and enforce precisely so performance is a durable team property, not a one-time fix.
Heads-up It will: new dependencies, new N+1s, and new allocations creep in continuously. Without a CI gate or budget, the regression is invisible until users feel it.
Recap
Every question reduced to the same loop the track is built on: profile before you guess (Amdahl caps the payoff of optimising the wrong thing), classify the dominant cost into its shape — allocation/GC, N+1 round-trips, per-op fixed cost, client CPU bytes — fix it at the layer where that cost actually lives, then verify under identical load and enforce the gain in CI. Performance is not a project you finish; it is this loop you keep running.