Day 100 — your interview operating manual

One hundred days ago the plan was to learn system design and be bulletproof on two resume projects. This last article is not new material — it is the operating manual you keep after the course ends. Four things: the map from every resume bullet to the code behind it, the script for the things you do not know, the reconciliation of two resumes that describe one Zoth differently, and the maintenance drill that keeps this from decaying.

The resume-to-code map

For each bullet, you should be able to name the file, the decision, and the trade-off in under thirty seconds. This is the actual deliverable of the last hundred days.

Popin Tech — MTTD. OpenTelemetry SDK per service, one shared instrumentation package, OTLP to a collector, fan-out to Better Stack. Decision: centralized resource attributes and a shared package so no service hand-rolls a tracer. Trade-off: instrumentation overhead and a new dependency, bought back with sampling and async batched export. Metric: alert-to-trace-correlation time (Day 96).

Popin Tech — security reviews. Matrix of actors × actions × expected outcomes across 10+ endpoints; four failure shapes (IDOR, missing function-level authz, mass assignment, horizontal/vertical confusion); 401 vs 403 vs masked 404; generic error envelope; granular RBAC; time-bound privileged access; 20+ authorization integration tests; audit logging (Day 98).

Zoth — IGA/JIT platform. PostgreSQL for state, RabbitMQ for async provisioning, pgvector for the advisory knowledge base. Decision: Postgres-only until a measured need forces otherwise. Trade-off: vertical scaling ceiling in exchange for one consistency model and one thing to operate (Day 5).

Zoth — six-state JIT lifecycle. Request → pending → approved → active → expired → revoked, with provisioning as an event-driven side effect so user-facing writes never pay for connector latency. Trade-off: eventual consistency between the workflow state and the external system, reconciled by idempotent retries and the outbox (Days 11, 60).

Zoth — hybrid authorization with advisory RAG. Deterministic RBAC guardrails decide; the RAG layer only advises, with a hard architectural guarantee of zero advisory bypass. Trade-off: you give up "the model might be right more often" in exchange for provable policy enforcement — and in access governance, provability wins (Day 63).

Zoth — microservices runtime on AKS. Three deployables (api, emitter, alerting), Kustomize overlays, liveness/readiness/startup probes, ACR, OTel end-to-end including across the broker via message headers. Trade-off: operational surface and cost (~$30/month at this scale) in exchange for isolating the alerting failure domain from the request path (Days 6, 84, 85).

Traverse — 100+ users, capture pipeline. Extension intercepts network responses in the page's main world, platform adapters normalize judge payloads, backend dedups on an idempotency key plus device id. Trade-off: relying on third-party response shapes, mitigated by adapters and contract tests (Day 21).

Traverse — the 50× latency win. The fact/derivation split: submissions and solves are durable facts written synchronously; revisions, streaks, rings, achievements, and notifications are derivations computed by workers. That is what let the 15-second LLM ladder leave the request path. Trade-off: derived state is eventually consistent and must be rebuildable — which is why Redis losing a job degrades features instead of corrupting truth (Days 4, 59, 72).

The honest-gaps script

The single most valuable habit in this course: know which parts of your resume you cannot defend in depth, and say so before you are caught. You have identified four:

• The extension's client-side internals — MAIN-world versus isolated-world interception, message passing, and the iOS client's state management. Script: "That is the layer I have spent least time in recently. I can describe the architecture and the contract it satisfies, but I would not claim to be fluent in the interception details today — it is next on my list."
• Zoth's audit-chain write path — you found the read-modify-write race yourself (M-8). Script: "The chain is a read-modify-write on the previous hash, which is safe at one writer and a correctness landmine the moment you scale the writer. I found it in my own audit and scoped the fix as a serialized append or a single-writer claim." Naming your own bug is worth more than pretending it does not exist.
• Zoth's backup story — you audited it and found it weaker than Traverse's. Script: "Traverse has WAL archiving to S3 with a five-minute RPO and an offsite copy; Zoth's is weaker and I named that as the first thing to fix. That asymmetry is real and I would not defend it."
• The RabbitMQ claim on the Traverse resume — the implementation is BullMQ on Redis; RabbitMQ is the broker in Zoth (Day 94). Script: the exact wording is in Day 94; the shape is "my resume summarizes the pattern as a message queue; the implementation is BullMQ over Redis and RabbitMQ is my other project. The architectural decision is identical — decouple ingestion from slow side effects — and here is why each fit its context."

The pattern across all four: state the boundary, state the reason, state the next step. Interviewers do not penalize a known boundary; they penalize a discovered bluff.

Two resumes, one Zoth — say it deliberately

Your backend resume calls Zoth an IGA and JIT access platform built on PostgreSQL, RabbitMQ, pgvector, microservices, AKS, and OpenTelemetry. Your security resume calls it an enterprise Zero Trust JIT access governance platform enforcing least privilege, with IGA/PAM lifecycle, a hybrid authorization and risk engine, CIEM connectors, and tamper-evident audit for SIEM ingestion and PCI-DSS/SOX recertification.

Same system. The difference is which layer of the same architecture each framing emphasizes: one leads with the technology and the async pipeline, the other with the security property the technology delivers. Both are accurate — but you must be able to answer the obvious follow-up: "which is it?"

The script: "Both. It is a Go backend with PostgreSQL, RabbitMQ, and pgvector, and the reason it exists is to eliminate standing privilege. So when I describe it to a backend audience I lead with the architecture — the outbox, the six-state workflow, the claim-based concurrency — and when I describe it to a security audience I lead with the properties that architecture guarantees: least privilege by construction, policy that cannot be bypassed by the advisory layer, and audit that is tamper-evident. Same code, two entry points."

Two smaller discrepancies worth pre-empting, both from the resumes: the "5+ ephemeral access states" phrasing versus the six-state machine (five transitions plus the terminal state — say "six states, which covers the five access states plus terminal revocation"), and the connector list. Zoth's implemented connectors are GitHub (fully functional), Notion (SCIM group operations), and Azure (discover-only — the connector can enumerate but NewFromConfig leaves the RBAC/Graph clients nil, so grant and revoke return ErrUnsupported). The security resume lists AWS and Slack as part of the connector story; the architecture is extensible to them and there is a connector interface for it, but they are not implemented. Script: "GitHub and Notion are implemented end-to-end; Azure is discovery-only today; AWS and Slack are named in the architecture as the next connectors through the same interface. I would rather be precise about which three are real." Precision about a short list is far more impressive than a long list you cannot open.

The weekly drill (30 minutes, forever)

Everything above decays without use. The maintenance loop is deliberately small:

1. Pick one resume bullet at random. Re-derive it from the code — open the file, read the decision, say the trade-off out loud. Thirty seconds of retrieval beats thirty minutes of re-reading.
2. One whiteboard prompt, one timer. Run the Day 99 loop once a week, rotating the prompt type. Grade with the six-dimension rubric.
3. Add one row to your gap list. Every week, find one thing you cannot defend and write the script for it. The list shrinks only if you feed it.
4. Re-read your own audit findings. The bugs you found in your own systems — the audit-chain race, the unmounted rate limiter, the transient DeliveryMode, the commit-then-enqueue gap — are your best interview material, because nothing demonstrates judgment like naming your own weakness first.
5. Rotate, do not serialize. The lesson from the very beginning of this course: doing one thing for months means forgetting the earlier thing. Interleave — one systems topic, one project deep-dive, one design drill — and space the repeats.

The closing thought

The reason this course was structured as odd days and even days was never really about system design versus project knowledge. It was about the thing interviewers are actually measuring: can you connect a general principle to a specific decision you made and paid for? Anyone can define consistent hashing. Very few people can say "here is where that bit me, here is what I chose instead, and here is the cost I accepted."

You have two systems, one internship, and a hundred days of connections between them. That is a genuinely unusual position for a candidate at your stage. The material is done; the only remaining variable is repetition.