Recon streaming and quota engineering
The unbounded-upload problem, solved with streaming, atomicity, and quotas — plus the ops around it.
Know your own system
The full engineering story of the least-conventional path in your codebase — and why it's a good interview exhibit.
The problem shape
The extension captures platform traffic (problem pages, judge responses, code submissions) as bundles — potentially tens of MB per session, unbounded per user, arriving from a browser context you don't fully control. Constraints: small VPS (disk is finite), no user-facing value (diagnostic only), retry-prone client, and a strict rule that this path must never degrade the submission hot path.
The design decisions, each with its reason
- Route before the JSON parser: the body is unbounded;
express.json's 10 MB limit would reject it, and buffering multi-MB bodies would stall the event loop (Day 7). The handler consumesreqas a stream. - Stream to disk in chunks: constant memory regardless of size — the handler never holds the whole bundle. (The same principle as WAL archiving and S3 multipart: stream, don't buffer.)
.partialthen atomic rename: complete-or-invisible (Day 80's principle).- Per-platform quota (
KEEP_PER_PLATFORM): retention is a count per platform, pruned on flush — bounded disk with the least-valuable data evicted first (oldest dumps). This is a retention policy declared at birth (Day 55's rule). - Digest email after flush: one summary per flush instead of per-bundle noise — the batch-notification instinct (Day 23's batching, applied to humans).
- Separate rate limiter (
reconLimiter: 60/15 min): recon is expensive and non-critical — its own budget so it can't consume the submission path's allowance (a bulkhead, Day 51). - Separate auth token (
RECON_TOKEN, constant-time compare): capture dumps are diagnostic and shouldn't ride user JWTs — a machine credential for a machine path (and note the timingSafeEqual detail from Day 24).
The ops around it
Disk monitoring (the quota bounds it, but the VM also holds Postgres + Redis + Docker images), the check-redis-memory.sh-style cron precedent for alerting, and the honest gap: no S3 offload for dumps (deliberate cost choice) — so disk pressure is a real failure mode, mitigated by the quota rather than eliminated. The upgrade path if dumps became valuable: stream to S3 with a lifecycle rule (cheap classes for old dumps) instead of local disk — the code change is a destination swap because the streaming interface is already there.
Why this is a strong interview exhibit: it demonstrates (a) recognizing an unbounded input and refusing to buffer it, (b) choosing the cheapest storage that meets the requirement rather than the default, (c) inventing atomicity from primitives (rename), (d) declaring retention instead of hoping, and (e) isolating a non-critical path so it can't harm the critical one. That's five distinct senior instincts in one feature — worth 90 seconds of any interview.
Bulletproof your resume
Say these answers aloud before moving on
These are the follow-ups an interviewer will actually ask about your projects.
Why stream to disk instead of buffering the recon bundle in memory?
Because the size is unbounded and the process is shared: a few concurrent multi-MB bundles would balloon RSS and stall the single event loop during parsing/serialization, degrading the submission path — the one thing this feature must never touch. Streaming keeps memory constant (chunk-sized), and the .partial-then-rename discipline keeps partial writes invisible. It's the same decision as mounting before express.json: the route's whole design is shaped by refusing to buffer.
How do you bound disk usage for recon dumps?
A per-platform count quota (KEEP_PER_PLATFORM) pruned on each flush — retention declared as data arrives, evicting the oldest dumps first. Combined with the recon-specific rate limiter, the worst case is bounded by quota × bundle size, which I can state as a number. The remaining risk is that the quota lives on the same volume as Postgres and Redis, so I monitor disk; the structural fix (offload to S3 with lifecycle rules) is scoped but deliberately not built, because the data is diagnostic.
What's the security model for this endpoint?
A dedicated machine token (RECON_TOKEN) compared in constant time, separate from user JWTs — capture dumps are a system path, not a user path, so credential separation limits blast radius (a leaked recon token can't read user data). Plus its own rate limiter so abuse can't starve the API, size limits on the stream, and no direct serving of stored dumps (they're internal diagnostics). The residual gap I'd name: no per-source quota — a single compromised extension could still fill the quota faster than others; per-source keying would fix it.