MySmartCoPilot
Ask Passes Your pass 7 days left 1 day left Last day

Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

System Design (High-Level Design) Module 5

APIs and communication patterns interview questions

Interview questions on APIs and communication patterns: warm-ups, then what each harder question tests and how a good answer starts.

25 questions: 5 warm-ups and 20 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

  1. Fresher

    How do REST, gRPC and GraphQL differ?

    Answered in the lesson API styles and HTTP semantics for designers

  2. Fresher

    A response is 429 with Retry-After: 30. What should the client do?

    Answered in the lesson API styles and HTTP semantics for designers

  3. Fresher to mid

    What is an idempotency key, and why does a retried POST need one?

    Answered in the lesson Idempotency keys and safe retries

  4. Fresher to mid

    Why do deep pages get slower with OFFSET pagination?

    Because the database cannot jump straight to the 10,000th row of a sorted result. To answer LIMIT 20 OFFSET 10000 it walks the index, or sorts the rows, from the start, reads 10,020 rows and throws the first 10,000 away, so the work grows with the page number: page 1 takes milliseconds, and a page thousands deep on a large table can take seconds. Keyset pagination avoids it. The client sends the sort key of the last row it saw, and the query asks for the rows after that key, which an index on the sort columns finds with one seek, so every page costs about the same. Offsets also shift when rows are inserted or deleted between requests, so items repeat or go missing.

    From the lesson Pagination at scale: offset, cursor and keyset

  5. Fresher to mid

    Why must a webhook receiver expect to receive the same event more than once?

    Because senders deliver at least once. A sender counts a delivery as successful only when a 2xx answer arrives in time, so if the answer is lost, arrives after the sender's timeout, or the receiver crashes after acting but before answering, the sender delivers the same event again, often for days. A sender that waited for certainty would lose events instead. The receiver therefore keeps the id of every event it has processed, such as the webhook-id header, in the same transaction as the event's effect: a repeat finds its id, answers 2xx and does nothing. The same check, together with a recent signed timestamp, stops an attacker who replays a captured delivery.

    From the lesson Webhooks: signing, retries and replay defence

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

  1. Mid to senior

    A ticketing platform has partner travel agencies that integrate over the internet, a mobile app whose home screen combines data from six services, and 40 internal services written in Go, Java and Python. Which API style do you give each audience, and what does each choice cost you?

    What it tests
    Matching API styles to clients and teams, knowing what each style gives up, such as caching, browser support and cost control, and combining styles in one architecture.
    First step
    Sort the audiences by who controls the client: partners you will never see, an app you ship yourself, and services you own on both ends. Then name what each needs most: plain HTTP with caching, fewer round trips per screen, or typed contracts with deadlines.
    Follow-ups

    From the lesson API styles and HTTP semantics for designers

    Opening the model answers with your pass…

    Model answers open with any MySmartCoPilot pass.

    • Pro pass · 1 week₹79$2.99
    • 30 days₹179$5.99
    • 1 year₹1,699$45

    One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

    Choose a passI have a licence key

    It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  2. Mid to senior

    Your shared HTTP client library retries every failed request three times, immediately, on any 5xx status or timeout. After an incident, some orders were created twice and a struggling service was flooded. Redesign the retry policy using methods, status codes and Retry-After.

    What it tests
    Applying safe and idempotent method semantics to retries, reading status codes as instructions, and backing off without amplifying an outage.
    First step
    Split every retry decision into two questions. May this request be repeated at all? That depends on the method and on whether it carries an idempotency key. Should it be repeated now? That depends on the status code, on Retry-After and on how many retries this client has already sent.
    Follow-ups

    From the lesson API styles and HTTP semantics for designers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  3. Mid to senior

    Checkout calls inventory, payments, fraud scoring, email and loyalty services synchronously, one after another. Last week the email provider was down for 40 minutes and no orders could be placed. Redesign which calls stay synchronous, and say what the shopper sees now.

    What it tests
    Separating what an order needs before its commit from what can follow it, putting numbers on a chain's availability, and handling the product and failure consequences of asynchronous work.
    First step
    Sort the five calls by one question: can the order be committed without this answer? Inventory and payments are needed before the commit, fraud scoring probably is, and email and loyalty are not, so those two can move behind a queue.
    Follow-ups

    From the lesson Synchronous vs asynchronous communication

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  4. Mid to senior

    Design the API that exports a merchant's transactions as a file. Small exports finish in 2 seconds, large ones take 20 minutes. Walk through every request and response from the first click in the browser to the download, including the failures.

    What it tests
    Applying asynchronous request-reply in HTTP detail: status codes, headers, operation states, retention, cancellation and safe retries of the submit.
    First step
    Start with the submit: validate it, then answer 202 Accepted with a Location header that points to a status resource and a Retry-After header, so the browser knows where to ask and how often.
    Follow-ups

    From the lesson Synchronous vs asynchronous communication

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  5. Mid to senior

    After loyalty points and address changes moved to a queue with several consumers, some customers got double points and some addresses went back to an old value. Explain both bugs from the queue's delivery guarantees, then fix them without giving up parallel consumers.

    What it tests
    At-least-once delivery and acknowledgements, idempotent consumers, ordering per key and versioned updates.
    First step
    Trace one message through delivery, processing and acknowledgement. If the consumer crashes or times out after processing but before acknowledging, the queue delivers the message again, and the points are added twice.
    Follow-ups

    From the lesson Synchronous vs asynchronous communication

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  6. Mid to senior

    A food-delivery app shows each order's status (accepted, cooking, picked up, nearly there) to 2 million daily users, about 300,000 of them with an active order at the dinner peak. Choose how status updates reach the web and mobile apps, and size the connection tier.

    What it tests
    Choosing a delivery technique from direction and frequency, estimating connections, servers and heartbeats, and designing catch-up for clients that drop.
    First step
    Start from the traffic, not the technology: updates flow one way, an order changes state about five times in 40 minutes, and only users with an active order need a connection, about 300,000 at the peak.
    Follow-ups

    From the lesson Real-time delivery: polling, SSE and WebSockets

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  7. Mid to senior

    Every deploy of your WebSocket gateway disconnects about 300,000 clients, and for several minutes afterwards the sign-in service is overloaded and many clients fail to reconnect. Explain the storm, then change the clients and the deploy so that the next one is quiet.

    What it tests
    Synchronised retries, backoff with jitter, admission control and connection draining, with the reconnection wave put into numbers.
    First step
    Put numbers on the wave: 300,000 clients reconnecting within a second or two, each needing a sign-in check, against a sign-in service sized for its normal rate. Then look at what each client does when its check fails.
    Follow-ups

    From the lesson Real-time delivery: polling, SSE and WebSockets

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  8. Mid to senior

    Chat users say some messages never appear after their phone switches from Wi-Fi to mobile data, and a few appear twice. Messages are pushed over WebSockets from several gateway servers. Design delivery so that a reconnecting client misses nothing and shows nothing twice.

    What it tests
    Treating push as a fast path over a durable store, ids per conversation, client cursors, de-duplication on the client and the order of storing and publishing.
    First step
    Find where a message can fall between two connections: the network switch kills the old TCP connection, and anything pushed into it after the phone stopped reading is lost unless the client can ask for it again.
    Follow-ups

    From the lesson Real-time delivery: polling, SSE and WebSockets

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  9. Mid to senior

    Your mobile app uses JWT access tokens that are valid for 24 hours. Users who sign out, and employees whose access was removed, can still call the API for up to a day. Fix revocation without adding a database lookup to every request.

    What it tests
    Why self-contained tokens resist revocation, sizing token lifetimes and deny lists, and using refresh tokens and sessions correctly.
    First step
    Name the window first: a token stays valid until its exp, so the exposure equals the token's lifetime. Shrink that window, then decide which events need faster revocation than the new lifetime allows.
    Follow-ups

    From the lesson Authentication and authorisation for services

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  10. Senior to staff

    Forty internal services call one another with one shared API key that sits in every service's configuration. Design service-to-service authentication and authorisation that would limit the damage if one service were compromised.

    What it tests
    Workload identity, mutual TLS and short-lived credentials, least privilege between services, and passing the end user's identity downstream safely.
    First step
    Ask what someone holding the shared key can do today: call every service as any service, for as long as the key lives, because it never expires and identifies nobody. Each service needs its own identity, and each identity a list of what it may call.
    Follow-ups

    From the lesson Authentication and authorisation for services

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  11. Mid to senior

    In a document-sharing product, any signed-in user can read another company's document by changing the id in the URL, although the API gateway validates every token. Explain the flaw and design the permission checks, including sharing with teams and folders.

    What it tests
    Recognising broken object-level authorisation, placing checks in the service that owns the data, and modelling sharing as relationships inside a tenant boundary.
    First step
    Separate the two checks the system needs. The gateway proves that the caller is a valid user who may read documents in general; only the documents service can say whether this user may read document 812. That second check is missing.
    Follow-ups

    From the lesson Authentication and authorisation for services

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  12. Mid to senior

    Your payments API stores idempotency keys, yet a few customers were charged twice. Both charges carry the same key and reached two servers 40 milliseconds apart. Explain how that happened, then redesign the key handling so it cannot happen again, including what the second request receives.

    What it tests
    Check-then-act races, atomic claims with unique constraints or conditional writes, in-progress states, 409 against waiting, and recovery from a crash around an external side effect.
    First step
    Walk through the two requests step by step. If each server looks the key up, finds nothing and saves the key only after charging, both lookups can miss, because neither request has written anything yet. The fix must make claiming the key a single step that only one request can win.
    Follow-ups

    From the lesson Idempotency keys and safe retries

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  13. Mid to senior

    A partner sends its daily batch number as the Idempotency-Key with every payout in that batch. Some payouts silently returned an earlier payout's response, and one partner received another partner's payout details. What went wrong on each side, and what must the server enforce?

    What it tests
    Keys that name one operation, request fingerprints and 422 on a mismatch, scoping keys to the caller, validating the key format, and what a replay may reveal.
    First step
    Separate the two failures. Reusing one key for many payouts is the client's bug: the key no longer names one operation, so the server replays the first response. The leak is the server's bug: it looked keys up without the caller's identity, so another partner's identical key matched.
    Follow-ups

    From the lesson Idempotency keys and safe retries

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  14. Mid to senior

    Your API receives 600 POST requests a second, on average, that carry idempotency keys. How long do you keep the keys, where do you store them, and what does that cost? Then explain what happens when a phone app retries a payment after two days offline.

    What it tests
    Choosing a retention window from how clients retry, sizing the storage and the write load, expiring keys cheaply, and handling retries that outlive the window.
    First step
    Start from the clients, not the database: list how long each kind of client may keep retrying the same operation, and make the window outlast the longest of them. Then size it: 600 a second is about 52 million keys a day.
    Follow-ups

    From the lesson Idempotency keys and safe retries

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  15. Mid to senior

    A social feed API uses ?page=N&size=20 with OFFSET. Users report posts appearing twice and posts they never saw, and page 400 takes three seconds. Redesign the API and the query, and explain how you move existing clients to it.

    What it tests
    Explaining offset drift, keyset queries with a unique tie-breaker and a matching index, opaque page tokens, and moving clients over without breaking them.
    First step
    Explain both symptoms with one cause: offsets count positions, and new posts at the top move every position between two requests. Then replace the position with a key: ask for the posts after the last one the client saw, ordered by created_at and then id.
    Follow-ups

    From the lesson Pagination at scale: offset, cursor and keyset

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  16. Mid to senior

    An admin console lists orders from a 40-million-row table, filtered by status and a date range, and shows "page 37 of 150,000" with a box to jump to any page. Staff run broad filters, and the database is struggling. Which parts of that page can you keep, and at what cost?

    What it tests
    The cost of exact counts and deep offsets, estimates and capped depth, jumping by value instead of by position, and agreeing an interface with its users from numbers.
    First step
    Cost each feature on its own. "Of 150,000" needs a count of all 3 million matching rows on every page view, and a jump to page 100,000 needs an offset of about 2 million rows. Neither is needed to show page 37, so ask which of them staff really use.
    Follow-ups

    From the lesson Pagination at scale: offset, cursor and keyset

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  17. Senior to staff

    Orders are sharded by customer across 16 databases. Support staff need one list of all orders from the last day, newest first, 50 a page, with stable paging while new orders arrive. Design the pagination, and say what each page costs.

    What it tests
    Scatter-gather with a global keyset cursor, tie-breakers unique across shards, the cost of a page in rows sent, and when a secondary index or a search store is the better answer.
    First step
    Notice that no shard can answer alone: page 1 may hold orders from any of them. Ask every shard for its newest 50 rows after the cursor and merge them; then work out what each page costs and what the cursor must contain.
    Follow-ups

    From the lesson Pagination at scale: offset, cursor and keyset

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  18. Senior to staff

    Design webhook delivery for a payments platform with 50,000 merchant endpoints and 2,000 events a second at peak. Some endpoints are down for hours, and a few answer slowly. Cover queuing, retries, ordering and what merchants can see.

    What it tests
    Isolating endpoints from each other, retry schedules and dead letters, timeouts and concurrency caps, at-least-once delivery, and the tools that let merchants run their side.
    First step
    Start by protecting healthy endpoints from broken ones: in one shared queue, a slow endpoint holds workers and delays everyone. Give each endpoint its own queue, or at least its own concurrency cap and backoff state, then work out the retry schedule and the numbers.
    Follow-ups

    From the lesson Webhooks: signing, retries and replay defence

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  19. Mid to senior

    Your shop's endpoint receives payment-succeeded webhooks and marks orders paid. A security review found that anyone can post a fake event, and that a captured real event could be replayed. Harden the receiver step by step, without missing genuine payments.

    What it tests
    Verifying signatures over the raw bytes, constant-time comparison, timestamp windows, deduplication by id, secret rotation, and confirming the state with the provider.
    First step
    Verify before you act: recompute the provider's HMAC over the exact bytes of the body with the endpoint's secret, compare it in constant time, and reject anything that does not match. Then decide what stops a request that is validly signed but old: the timestamp and the event id.
    Follow-ups

    From the lesson Webhooks: signing, retries and replay defence

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  20. Senior to staff

    Customers register webhook URLs on your platform. One registered a URL on a domain the attacker controlled, which pointed to a public address when it was checked. A week later the attacker held your cloud credentials. How could your deliveries have leaked them, and how do you make the sender safe?

    What it tests
    Server-side request forgery through webhooks: DNS rebinding, redirects, internal and metadata addresses, connecting to the checked address, egress proxies and network isolation.
    First step
    Find the moments when the address was checked and when it was used, and ask what the attacker could change in between. A check made once, at registration, says nothing about the deliveries that follow it.
    Follow-ups

    From the lesson Webhooks: signing, retries and replay defence

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

All System Design (High-Level Design) interview questions · The System Design (High-Level Design) track