OphirCloud AcademyBack to the syllabus

Phase 4 · Days 51–60 · 5 briefs

Design it, then check it against the rubric.

Draw on any whiteboard you like — Excalidraw or paper. Nothing on this page is graded: the rubric is the check, and it is deliberately written so you can mark your own drawing honestly. If a line in the rubric cannot be found in your diagram, the diagram is missing it.

Brief 01

Open a canvas

Core concepts under load

Take a single-service web app and show what breaks first as traffic grows 100×. Draw the path from a browser to the database and mark the point where each of these enters: a load balancer, a cache, a read replica, a queue, and a CDN. For each addition, say what it buys and what it costs.

Constraints

  • Assume 10k requests/second at peak, read-heavy (95% reads).
  • One writer database, no sharding allowed in this exercise.
  • Cache invalidation must be explained, not hand-waved.
  • State what happens to an in-flight request when a node dies.

Rubric

  1. The bottleneck order is justified with a number, not a feeling.
  2. The cache has a stated eviction policy and a staleness bound.
  3. The queue has a named consumer and a dead-letter path.
  4. Failure of each component is drawn, not implied.
  5. One trade-off is named as a trade-off, not a win.

Brief 02

Open a canvas

Design a URL shortener

Design a service that turns a long URL into a short code and redirects in under 10 ms at the 99th percentile. Cover code generation, collision handling, the read/write ratio, analytics on clicks, and expiry.

Constraints

  • Codes must be unguessable enough that enumeration is not a feature.
  • Redirects must not depend on a write path.
  • Expired links must stop working without a background scan being the only guard.
  • Analytics must not slow the redirect.

Rubric

  1. The read path is drawn separately from the write path.
  2. Code generation states the collision strategy.
  3. A cache sits in front of the redirect with a stated miss path.
  4. Click analytics is asynchronous and loss-tolerant.
  5. Expiry is enforced at read time.

Brief 03

Open a canvas

Design a notification system

Design a system that delivers email, push and in-app notifications for 50 million users, with user preferences, retries and deduplication. Show how one event fans out and what happens when a provider is down.

Constraints

  • A user must never get the same notification twice for one event.
  • Provider outages must not lose notifications.
  • Preferences are per channel, per user, and change at any time.
  • At-least-once delivery is acceptable; duplicate display is not.

Rubric

  1. Fan-out is drawn as stages with backpressure.
  2. Deduplication has a concrete key and a storage choice.
  3. Retries have a schedule and a terminal state.
  4. Provider failure is handled per channel, not globally.
  5. Preference changes are respected without replaying the whole queue.

Brief 04

Open a canvas

Design a file storage service

Design a Dropbox-like service: upload, download, sync across devices, sharing and versioning. Decide what is stored in the database and what is stored in object storage, and draw the consistency boundary between them.

Constraints

  • Files are up to 5 GB; resumable uploads are required.
  • Metadata and bytes must not drift out of sync.
  • Sharing links need revocation and expiry.
  • Sync must handle two devices editing the same file.

Rubric

  1. The metadata/bytes split is explicit, including failure between them.
  2. Upload is chunked and resumable, with a stated chunk size.
  3. Conflict resolution is named (last-write-wins is a choice, not an accident).
  4. Sharing links are authorised at read time.
  5. Storage growth is estimated, not ignored.

Brief 05

Open a canvas

Design an end-to-end LLM inference platform

Design the platform this cohort builds: a request arrives at an API, is authenticated and rate-limited, routed to an inference replica, streamed back token by token, and billed. Cover model loading, GPU scheduling, autoscaling, caching, observability and failure of a replica mid-stream.

Constraints

  • Time-to-first-token is the user-visible metric; throughput is the cost metric.
  • Models are large: loading is slow and cannot happen per request.
  • One replica can fail mid-stream without retrying the whole answer silently.
  • Rate limits are per tenant and per model.
  • Cold start must be bounded and visible.

Rubric

  1. The request path names every hop and where state lives.
  2. GPU scheduling and model loading are drawn as a separate warm path.
  3. Autoscaling has a signal (queue depth or TTFT), not just CPU.
  4. Streaming failure is handled without duplicating tokens.
  5. Observability covers TTFT, throughput and GPU health.

The last brief is the cohort itself: the platform you built in Phases 1–3, drawn end to end. If the diagram needs a component you did not build, that is the gap the phase was pointing at.