Requirements clarification & non-functional requirements
The first five minutes of every design interview — and the step most people skip on their own projects.
Concept → your projects
Every system design conversation starts the same way: someone says "build me X" and the amateur starts drawing boxes. The professional starts asking questions. There are two kinds of requirements, and you must separate them explicitly.
Functional requirements (FRs) — what the system does. "A user requests access to a resource; an approver approves it; access is granted for a bounded time; access expires automatically."
Non-functional requirements (NFRs) — how the system behaves while doing it: latency, availability, durability, consistency, security, cost, compliance. NFRs are where all the interesting tradeoffs live, and they're the ones interviewers actually probe.
The NFR checklist
| NFR | The question | Typical knob |
|---|---|---|
| Latency | p50 / p95 / p99 targets, read vs write | caching, async, indexing |
| Availability | how many nines, and who measures it | replication, retries, LBs |
| Durability | what may never be lost, ever | WAL, backups, replication |
| Consistency | can a stale read happen? for how long? | sync vs async replication, queues |
| Security | who can see what? what's the blast radius? | authn/authz, isolation, audit |
| Cost | what's the monthly budget? | instance sizes, # of services |
| Compliance | which auditors will read your logs? | retention, audit trail, recert |
Back-of-envelope rule: attach a number to every NFR. "Fast" is not a requirement; "p95 under 300 ms" is.
How Zoth was actually specified
Look at docs/PLAN.md in your repo — you did this properly, and that's an interview story in itself. The plan pins down:
- The scale ceiling deliberately small: single-node Postgres, single-replica RabbitMQ (1 Gi PVC), a 1-node AKS cluster (~$30/month, documented in
DEVOPS.md §16). Availability target is implicitly "one node, self-healing via Kubernetes probes" — not five nines. That's cost-aware architecture: you explicitly traded availability for a student budget and documented the tradeoff. - Security as the #1 NFR: 100% of access decisions must pass the structured policy engine (
policies.access_rulesJSONB) — the RAG layer is advisory-only by construction. Your INDEX.md states this as a first-class architectural decision. In interview language: "correctness/safety was the consistency requirement; the LLM layer was allowed to be wrong because it never holds authority." - Auditability: append-only, hash-chained
audit_logs— a durability+integrity requirement that would make an auditor happy (SOX/PCI-DSS recertification is literally a resume line on your cyber resume).
How Traverse was specified
Traverse's NFRs came from a real product decision: the submission write path had to feel instant, because the Chrome extension fires a POST on every LeetCode submission the user makes. The measurable NFR: end-to-end API response under write-heavy traffic. You hit 10s → 0.2s by moving AI analysis, achievements, streaks, and revision scheduling off the request path into BullMQ workers (commit 06ba1b3, "redis and BullMQ for submission APIs"). The commit message even documents the intended architecture:
Write Path: User → API → Database (immediate) → Queue (LSTM/Achievement/etc. logic) Read Path: User → API → Redis Cache → Database (if miss) → Redis (cache it)
Note the asymmetry — writes need correctness (idempotency), reads need freshness-tolerant speed (TTLs of 120–600 s). Two different NFRs, two different mechanisms.
The skill to practice today
Take any interview prompt ("design a URL shortener") and spend the first five minutes producing: 3 FRs, 5 NFRs with numbers, and one explicit "we will NOT do" list. The "not" list is the senior move — your repos already contain three great examples: no graph database (zoth 002_drop_neo4j.sql), no Kafka (work-queue semantics, not log semantics), no Redis in zoth (Postgres-only store). Every "no" you can justify is a tradeoff story interviewers remember.
Bulletproof your resume
Say these answers aloud before moving on
These are the follow-ups an interviewer will actually ask about your projects.
How did you decide on the non-functional requirements for Zoth?
Safety first: the policy engine had to be the sole decision authority with deterministic rules, because an IAM platform that wrongly grants access is worse than one that's slow. Latency was a soft target — approval workflows are human-paced, so seconds are fine. Cost was a hard constraint: ~$30/month Azure budget, which cascaded into 1-node AKS, single-replica RabbitMQ, and no managed databases. Auditability was non-negotiable: hash-chained append-only audit logs, because the domain (IGA) assumes auditors will read them.
Your resume says 'cut submission latency 50x'. Was that a requirement or a discovery?
A discovery that became a requirement. The Chrome extension posts on every submission; users were waiting up to 10 seconds because the request path synchronously called an LLM ladder (user Gemini key → Groq → G4F, 15 s timeout per provider). Once we measured where time went, the NFR became: DB write + enqueue must complete in ~200 ms; everything else is allowed to be eventually correct via the queue.
What's an NFR people forget that you explicitly handled?
Auditability/tamper-evidence. In Zoth every state change writes an audit row whose hash chains to the previous row (sha256(prev_hash || data)), so silent modification of history is detectable. Most side projects treat logging as an afterthought; in identity governance, the log IS the product — it's what SOC teams and PCI-DSS/SOX recertifications consume.