TopicsAPIs
APIs
HTTP semantics, retries, idempotency, GraphQL tradeoffs, and contract design.
Common tags: http, rest, graphql, idempotency
- APIs
GraphQL — Schema Design, N+1, Federation & When Not to Use It
Cluster · GraphQL
GraphQL is a query language plus a typed schema so clients can ask for the fields they need on one endpoint. This hub is the decision map for schema nullability, resolver N+1, federation, and when REST or gRPC is the better tool.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
Schema Design — Types, Nullability, Inputs & Evolution
Cluster · GraphQL
A GraphQL schema is a versioned product contract. Nullability, input types, and additive evolution decide whether the next ship breaks clients or only adds a field they can ignore.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
Resolvers & N+1 — DataLoader, Batching & Query Planning
Cluster · GraphQL
GraphQL walks the selection set and calls a resolver per field. A child fetch per parent row is the N+1 outage. DataLoader batches those keys inside a single request, and a join or a persisted plan beats the loader when the shape is fixed.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
Queries, Mutations & Subscriptions vs REST/gRPC
Cluster · GraphQL
GraphQL operations are Query for a read, Mutation for a write, and Subscription for a product event stream. Map them to REST methods and gRPC shapes, then leave CDN reads, idempotent POST retries, and mesh streams in their own clusters.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
Federation, Gateways & Schema Stitching Tradeoffs
Cluster · GraphQL
Federation, schema stitching, and a monolith schema are ownership models. A gateway is worth it when domain teams and a platform SLO both exist. It does not remove N+1, field AuthZ, or the need for a cost budget inside each subgraph.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
AuthZ, Complexity Limits & Abuse Protection
Cluster · GraphQL
A GraphQL endpoint lets the client choose depth, breadth, and aliases. Authentication at the door is not enough. Authorize each sensitive field, score the query, and prefer persisted documents for first-party apps.
Open study →- apis
- graphql
- schema
- n+1
- federation
- interview
- dataloader
- authz
- APIs
Unary vs Streaming RPCs — Client, Server, Bidi & Backpressure
Cluster · gRPC & Protobuf
gRPC RPCs are not only request/response. Four shapes — unary, server-streaming, client-streaming, bidirectional — change memory, latency, and failure modes. Senior interviews ask when each fits, how HTTP/2 flow control provides backpressure, and which anti-patterns (unbounded server streams, ignoring cancel) blow up production.
Open study →- grpc
- unary
- bidi
- backpressure
- flow-control
- http2
- interview
- APIs
Protobuf Schemas — Fields, Wire Types & Compatibility
Cluster · gRPC & Protobuf
Protobuf's wire identity is the field number, not the field name. Types, optional / repeated / map, proto3 defaults, reserved, and wire types determine whether two binaries can talk forever. Interviewers probe: can you add a field safely? Why never reuse numbers? What goes wrong with JSON mapping?
Open study →- protobuf
- wire-types
- schema-evolution
- compatibility
- contracts
- apis
- interview
- APIs
gRPC vs REST/JSON & GraphQL — When to Choose What
Cluster · gRPC & Protobuf
There is no universal winner. Choose gRPC for internal typed service meshes and streaming; REST/JSON for public, cacheable, browser-native HTTP; GraphQL when many clients need flexible graphs of data from a BFF. Honest senior answers include when REST wins — not only when binary RPC looks faster on a whiteboard.
Open study →- grpc
- graphql
- rest
- tradeoffs
- apis
- interview
- APIs
gRPC & Protobuf — Contracts, Streaming & API Evolution
Cluster · gRPC & Protobuf
gRPC is HTTP/2 + Protocol Buffers + generated stubs: a contract-first RPC stack for service-to-service calls. Interviewers care less about binary speed and more about contracts, streaming shapes, evolution rules, and when gRPC is the wrong tool (browsers without grpc-web, public REST ecosystems). This hub maps the cluster: schemas, unary vs streaming, deadlines/errors, load balancing/channels, and the REST/GraphQL decision matrix.
Open study →- grpc
- protobuf
- http2
- contracts
- api-evolution
- apis
- interview
- APIs
gRPC Load Balancing, Name Resolution & Channel Health
Cluster · gRPC & Protobuf
gRPC clients open a channel to a resolved set of addresses and may balance RPCs client-side (pick_first, round_robin, …) or through a proxy (Envoy/L7). Name resolution (DNS, xDS), keepalive, health checks, and sticky affinity for bidi decide whether streams survive deploys. Cross-link the general Load Balancing cluster — here we focus on gRPC-specific channel behavior.
Open study →- grpc
- name-resolution
- channels
- keepalive
- apis
- interview
- APIs
gRPC Deadlines, Cancellation & Error Model
Cluster · gRPC & Protobuf
gRPC calls carry a deadline (absolute time), not only a per-hop timeout. Cancellation propagates so servers stop work the client no longer needs. Errors are status codes + optional details + trailers, not HTTP status alone. Interviewers compare this to HTTP codes and ask which statuses are retryable.
Open study →- grpc
- cancellation
- status-codes
- trailers
- apis
- interview
- APIs
API Versioning Strategies — URL, Header & Query Tradeoffs
Cluster · API Design
Should we put /v1 in the path is a classic interview trap. Prefer additive, non-breaking evolution; version only when you must break contracts; then compare URL vs media-type/header vs query (api-version=) with Sunset and a migration window.
Open study →- apis
- rest
- http
- versioning
- compatibility
- interview
- APIs
Resource Naming & URI Design — Plurals, Case, IDs & Collections
Cluster · API Design
Almost every API design interview starts with a path sketch. Interviewers check plural nouns, verbs smuggled into URLs, kebab vs snake consistency, opaque IDs, and whether filters live in the query string. We design the nouns idempotent retries operate on — without re-teaching Idempotency-Key.
Open study →- apis
- rest
- http
- uri-design
- naming
- interview
- APIs
Path Nesting, Routing & Actions — Depth Limits & Sub-resources
Cluster · API Design
Nesting feels natural until clients need cross-org search, gateways rewrite paths, or authz must check every segment. Cap depth around 2–3 resource pairs, keep a canonical item URL, and model non-CRUD verbs as :customAction or /actions — not controller soup.
Open study →- apis
- rest
- http
- nesting
- routing
- interview
- APIs
Pagination, Filtering, Sorting & Partial Responses
Cluster · API Design
List endpoints make or break API UX. Interviewers ask offset vs cursor, why page 50 drifts under inserts, how to sort stably, where filters live, and whether fields= helps mobile. Prefer cursors for large append-heavy feeds; always define a total order.
Open study →- apis
- rest
- http
- pagination
- filtering
- sorting
- interview
- APIs
HTTP Methods & Status Codes for Resource APIs
Cluster · API Design
Interviewers expect CRUD mapped to methods and status codes clients can automate on. Always-200 with {success:false} is a classic fail. This lesson covers GET/POST/PUT/PATCH/DELETE, 201 Location, Prefer, If-Match, and the 4xx grid — pointing POST retries and 429 at the Idempotency and rate-limit docs.
Open study →- apis
- rest
- http
- status-codes
- methods
- interview
- APIs
API Design — Naming, Paths, Routing & Contracts
Cluster · API Design
Interviewers rarely ask you to design REST. They ask whether /getUser is wrong, how deep nesting should go, when to version, which status codes clients can trust, and how you paginate without breaking caches. This hub maps naming, nesting, methods/status, versioning, and list contracts.
Open study →- apis
- rest
- http
- naming
- routing
- interview
- APIs
Transactional Outbox & Inbox Patterns
Cluster · Idempotency
Dual-write is the bug. Write domain row + outbox row in one DB transaction; poller/CDC publishes; inbox dedupes at-least-once deliveries into effectively-once processing.
Open study →- software-engineering
- apis
- reliability
- messaging
- APIs
Retry Storms, Backoff & Jitter
Cluster · Idempotency
Naive retries amplify outages. Combine exponential backoff, full jitter, Retry-After, circuit breakers, client budgets, and idempotency keys.
Open study →- software-engineering
- apis
- reliability
- APIs
Request Fingerprinting for Idempotent APIs
Cluster · Idempotency
Canonical JSON (sorted keys, stable numbers) hashed with method+path; include/exclude map; Stripe-style 422 on mismatch; schema-evolution with null defaults.
Open study →- software-engineering
- apis
- reliability
- APIs
Idempotent HTTP Methods & Safe Retries
Cluster · Idempotency
RFC 9110 — safe vs idempotent. GET/HEAD/OPTIONS/TRACE safe; PUT/DELETE idempotent but not safe; POST not idempotent; PATCH depends. Idempotency-Key still needed for POST and for concurrent PUT races.
Open study →- software-engineering
- apis
- http
- APIs
At-Least-Once vs Exactly-Once Delivery
Cluster · Idempotency
At-most-once loses; at-least-once duplicates; exactly-once needs transactional producer+consumer+sink; effectively-once is idempotent consumers + dedup.
Open study →- software-engineering
- apis
- reliability
- messaging
- APIs
API Idempotency Keys
Cluster · Idempotency
Stripe-style Idempotency-Key for safe retries — fingerprint, unique (account,key), in_progress/completed, response cache, ~24h TTL.
Open study →- software-engineering
- apis
- reliability