Skip to content
Devgo

Paths

Guided sequences that take you from concept to a working mental model, one term at a time.

System design interview

A guided path through the concepts most interviewers probe: from requirements to a scalable architecture.

For: Engineers preparing for system-design interviews.

  1. 1
    Clarify requirementsAPI gateway

    Start with functional and non-functional requirements; capacity estimates shape every choice.

  2. 2
    Pick an API styleREST

    Decide REST vs gRPC vs GraphQL based on clients and contracts.

  3. 3
    Model the dataSharding key

    Choose a data model and the sharding key early — it constrains scale.

  4. 4
    Choose a databasePostgreSQL

    Relational vs key-value vs wide-column based on access patterns.

  5. 5
    Add cachingCache-aside

    Identify the hot set and cache it; pick a strategy and TTL.

  6. 6
    Handle async workKafka

    Use a queue/stream for decoupling, retries, and backpressure.

  7. 7
    Make it reliableRate limiter

    Add rate limiting, circuit breakers, and timeouts at the edge.

  8. 8
    Scale the readsCDN

    CDN + read replicas + caching for read-heavy paths.

  9. 9
    Reason about consistencyCAP theorem

    State your consistency model and the tradeoffs you accept.

Greenfield backend

Building a new backend service from scratch with sane defaults that won't immediately paint you into a corner.

For: Engineers starting a new service.

  1. 1
    Define the APIREST

    REST + OpenAPI is the pragmatic default; add gRPC later for hot internal calls.

  2. 2
    Pick the primary DBPostgreSQL

    Postgres is the safe default for most apps; shard only when you must.

  3. 3
    Add a cacheRedis

    Redis for sessions, rate limiting, and hot reads.

  4. 4
    Async via a queueSQS

    Use a managed queue for background jobs; Kafka if you need replay.

  5. 5
    Edge protectionRate limiter

    Rate limit + auth at an API gateway.

  6. 6
    ObservabilityOpenTelemetry

    Instrument metrics, logs, and traces from day one.

  7. 7
    ResilienceCircuit breaker

    Timeouts and circuit breakers on every outbound call.

Data-heavy service

When reads, writes, or analytics dominate and a single DB won't hold it.

For: Engineers scaling a data-intensive app.

  1. 1
    Choose OLTP vs OLAPClickHouse

    Separate transactional (Postgres) from analytical (columnar) stores.

  2. 2
    Shard for write scaleSharding key

    Pick a sharding key matching your access patterns.

  3. 3
    Precompute readsMaterialized view

    Materialized views / CQRS for expensive aggregations.

  4. 4
    Stream changesKafka

    CDC to Kafka to feed analytics and read models.

  5. 5
    Cache hot queriesCache-aside

    Cache query results with bounded TTL and invalidation.

  6. 6
    Plan capacityCapacity planning

    Forecast growth; reserve headroom for peaks.

Realtime service

Building a live, push-based experience (chat, dashboards, collab).

For: Engineers building realtime features.

  1. 1
    Pick a transportWebSockets

    WebSockets for bidirectional; SSE for one-way push.

  2. 2
    Scale connectionsRedis

    A pub/sub broker fans messages across server instances.

  3. 3
    Handle backpressureBackpressure

    Bound buffers and flow-control so slow clients don't OOM you.

  4. 4
    Persist messagesEvent sourcing

    Append-only logs per chat/channel for history and replay.

  5. 5
    Offline deliveryDead-letter queue (DLQ)

    Store-and-forward; deliver on reconnect; DLQ for failures.

  6. 6
    Optimistic UIOptimistic UI

    Reflect local edits instantly; reconcile on confirm.