How to pass the Provyn system design assessment

How the assessment works

System design questions are short-answer and code, graded by a senior engineer. There is no single correct answer. The rubric grades you on whether your reasoning is structured, your trade-offs are explicit, and your design actually solves the stated constraints.

Most questions give you a scenario with a load number (e.g., '10M requests per day, p99 latency under 200ms'). Your job is to show you know which decisions are driven by that constraint and which are independent of scale.

The rubric: what earns full points

Stating assumptions before starting. Real designs depend on requirements that are always underspecified. An engineer who jumps to 'use Kafka' without asking 'what is the message size?' is not showing senior-level thinking.

Explicit trade-off statements. Don't just name a technology — explain what you give up. 'PostgreSQL over DynamoDB because the query access pattern requires joins that are prohibitively expensive in a key-value model' earns points. 'I'd use Postgres because it's relational' does not.

Back-of-envelope math. If the prompt says 10M requests/day, you should compute requests/second, storage per request, total storage/year, and network throughput before picking a tier. Show the math, even rough math.

Caching: the most tested sub-topic

Every system design question involves a caching decision. Know the four patterns: cache-aside (application reads cache, falls back to DB, writes through application), write-through (writes go to both cache and DB), write-behind (writes go to cache, async to DB), and read-through (cache reads from DB on miss).

Know what to do about cache invalidation: TTL-based expiry is simple but causes stale reads; event-driven invalidation is correct but complex. The assessment will ask you to pick and justify.

Databases: selection criteria

SQL wins when: you need ACID transactions, your access patterns require joins across multiple entities, or your data model is highly relational and changes frequently.

NoSQL wins when: your access patterns are key-based with predictable hot paths, you need horizontal write scalability, or your schema changes frequently and you want schema flexibility.

The assessment will give you a scenario (e.g., 'a social graph with follower relationships') and ask which database type and why. The answer for graphs is usually neither — it is a graph database — and knowing that is itself a point.

How to structure a written design answer

Use this four-part structure: (1) Restate the requirements and state your assumptions. (2) Estimate the scale: QPS, storage, bandwidth. (3) Propose the high-level design with named components. (4) Walk through trade-offs and what you'd change under different constraints.

Don't write prose for the component list — use a diagram or a bulleted list of components with one-line descriptions. Save prose for the trade-off section, which is where points are won and lost.