40/60 Days System Design Questions

Your React dashboard freezes for 4 seconds every time a user uploads a CSV. Not a network freeze. A browser freeze. Tab unresponsive. Animations stuck. The "Page Unresponsive" dialog popping up on Chrome. Here's what's happening in prod: • User drops a 80MB CSV (200k rows, 40 columns) into the upload zone • Your code: Papa.parse(file, { complete: ... }) on the main thread • Parsing + validation + schema mapping = 3.8s of synchronous JS • During those 3.8s: scroll dies, the loading spinner stops spinning, input lag goes infinite • Your INP score on the perf dashboard is now red. Lighthouse is screaming. Product wants this fixed before the enterprise demo on Friday. Four options on the table: A) requestIdleCallback + time-slicing — chunk the parse into 5ms slices, yield between rows, let the browser breathe. B) Web Worker — move the entire parse + validation pipeline into worker.js, communicate via postMessage, main thread stays free. C) SharedArrayBuffer + Atomics — share the file buffer between main thread and 4 workers, parallelize the parse across cores, zero-copy. D) Compile the parser to WebAssembly — drop the JS parser, run a Rust CSV parser through WASM for near-native speed. All four ship in real frontend codebases. Three of them are the wrong pick for this specific problem. One of them is the boring, correct answer that Figma, Google Sheets, and Excalidraw actually run. One is the senior-engineer trap. Sounds sophisticated in design review. Doubles your infra complexity. Requires you to set COOP/COEP headers and break half your third-party embeds. Solves a problem you don't have. Pick one — A, B, C, or D — and tell me why. Full breakdown drops in the comments (including which option is the trap, and why the "faster parser" answer doesn't fix anything here). Drop your answer 👇 Top comments (5) Why B wins: The actual problem isn't speed. It's where the work runs. The main thread is the same thread that handles scroll, input, layout, paint, and animation. Anything synchronous on it = jank. Period. A Web Worker is a separate OS-level thread with its own event loop. You ship the file (transferable via postMessage with a Transferable so it's zero-copy), parse it over there, send back the parsed rows. Main thread stays at 60fps the entire time. INP drops from 3800ms to ~80ms. Done. This is what Figma does for its rendering pipeline, what Google Sheets does for formula recalc, what Excalidraw does for its scene processing, what VS Code Web does for syntax highlighting. Every serious browser-based product runs heavy compute in a worker. It is the boring, correct, ten-year-old answer. Why C is wrong (the SENIOR ENGINEER TRAP 🪤): SharedArrayBuffer + Atomics is the answer that sounds smart in a design review. "We'll parallelize across cores! Zero-copy! Lock-free!" Then you discover: • It requires COOP + COEP headers site-wide, which break Stripe Elements, YouTube embeds, Intercom, and half your analytics scripts. • A single 80MB CSV parse is embarrassingly serializable — splitting rows across 4 cores saves you ~2s while costing you weeks of cross-origin isolation hell. • You now own a custom thread pool in JavaScript. In 2026. SAB is the right answer for exactly two problems: real-time audio/video processing (where you need lock-free ring buffers between threads at 48kHz), and shared simulation state (think multiplayer game engines in the browser). A one-shot CSV upload is neither. Why D is wrong: WASM makes the parser faster. It doesn't move it off the main thread. A WASM parser running synchronously on the main thread still freezes the UI — just for 1.2s instead of 3.8s. You'd still need to put it inside a worker. So D isn't an answer; it's a possible optimization inside B. And honestly, Papa Parse in a worker is fast enough that you don't need it. Why C is wrong (the SENIOR ENGINEER TRAP 🪤): SharedArrayBuffer + Atomics is the answer that sounds smart in a design review. "We'll parallelize across cores! Zero-copy! Lock-free!" Then you discover: Some comments may only be visible to logged-in visitors. Sign in to view all comments.