RESTful API Design and HTTP Fundamentals Questions
Understanding REST architectural principles including resource-based URLs, proper HTTP methods (GET for safe retrieval, POST for creation, PUT for updates, DELETE for deletion), appropriate status codes (200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error), and stateless communication patterns. Ability to design simple API endpoints following REST conventions.
MediumSystem Design
73 practiced
Design an API gateway architecture for microservices that must enforce RESTful routing, request validation, per-client rate limiting, idempotency-key support for POST, and centralized telemetry export. Target load: 50k RPS, multi-region deployment. Describe components, data flow, where state is kept, and likely failure modes an SRE should plan for.
Sample Answer
Requirements clarified:- REST routing, request validation, per-client rate limiting, POST idempotency-key support, centralized telemetry, 50k RPS, multi-region.High-level architecture:- Global DNS + Anycast/Geo-load-balancer → Edge LBs (regional) → API Gateway fleet (K8s/autoscaled) → Service mesh / microservices- Observability: Sidecar/agent → OpenTelemetry Collector (regional) → Central backend (e.g., Tempo/Jaeger + Prometheus/remote_write + ELK/OLAP)- State services: Redis clusters (regional + cross-region replication or CRDT), durable DB for idempotency audit (Cassandra/Spanner) if stronger persistence needed- Control plane: Config store (GitOps), policy engine (OPA) for validation rules, API key/authn service, rate-limit config storeData flow (per request):1. Client hits regional Edge LB → routed to an API Gateway instance.2. Gateway enforces auth (API key / JWT), reads per-client policy.3. Validation: JSON/schema validated locally (OPA + JSON Schema).4. Rate limiting: check local token-bucket (fast, in-memory) + fallback to Redis-backed distributed limiter for cross-instance coordination. Reject 429 if exceeded.5. Idempotency for POST: if request has Idempotency-Key header: - Gateway checks regional idempotency cache (Redis). If hit, return stored response metadata (status + body or redirect to stored result). - On miss, gateway forwards to backend with a provisional lock (SETNX in Redis). Backend processes; gateway stores response with TTL in Redis and optionally writes durable record asynchronously.6. Forward to service mesh; record telemetry/traces and emit metrics to collector.Where state is kept:- Short-lived state: in-memory caches on gateway (policy cache, in-flight locks), Redis (rate-limit counters, idempotency cache).- Durable state: transactional DB for permanent idempotency records if required.- Config: Git + config store (etcd/consul).Scalability:- 50k RPS -> autoscale gateway pods per CPU/latency; shard rate-limit keys by client hash; use Redis clusters partitioned.- Multi-region: serve traffic locally; replicate critical records or make idempotency stick to region for latency and compensate with cross-region reconciliation.Likely failure modes & SRE mitigations:- Redis outage (rate-limits/idempotency): degrade gracefully — allow higher local rate-limit thresholds or “fail-open” with alerts; queue writes for idempotency and mark operations as eventually consistent.- Network partition between regions: idempotency duplication risk. Mitigate by using client-visible idempotency-key TTLs and global stable unique IDs; use durable reconciliation job to dedupe.- Hot clients exceeding capacity: implement client-level throttling + dynamic reconfiguration, backpressure and 429 with Retry-After.- Gateway overload: autoscale, circuit-breakers to backend, shed non-critical features (telemetry sampling).- Configuration drift causing policy errors: GitOps + canary rollout + validation tests.- Telemetry pipeline overload: adaptive sampling, local buffering, backpressure to collectors.- In-flight request loss on pod crash: use graceful shutdown and drain; persist minimal state in Redis to resume.Operational runbook notes:- SLOs: p99 latency, error rate, availability; define idempotency guarantee SLA.- Alerts: Redis latency/ops, rate-limit rejects spike, error injection tests, collector lag.- Chaos plans: simulate Redis failover, region blackout, and client replay to validate idempotency.Trade-offs:- Strong global idempotency (single source) increases latency; regional caches + async durable writes favor availability and lower tail latency.- Distributed limiter consistency vs throughput: use hybrid local + Redis for balance.This design gives high throughput, regional low latency, central telemetry, and practical failure modes with SRE controls.
MediumTechnical
74 practiced
Compare offset-based pagination and cursor-based pagination for a high-traffic REST API used for listing items. Discuss performance, correctness when data is changing during pagination, cacheability, and operational considerations from an SRE viewpoint.
Sample Answer
Offset-based pagination (limit/offset) and cursor-based pagination (opaque or encoded cursors pointing to position) each have trade-offs important to SREs.Summary:- Offset: client requests page N with offset = (N-1)*limit.- Cursor: client requests next page with a cursor token (e.g., last-seen id + tiebreaker).Performance:- Offset: For large offsets, DB must scan/skip rows (even with index) — queries degrade (O(offset)). In heavy-traffic listings this increases latency and IO; pagination beyond few thousand rows is costly. Caching helps for low offsets only.- Cursor: Uses indexed seeks (WHERE (pk, created_at) > cursor) — consistent, O(log n) per page. Lower DB CPU and IO under load.Correctness while data changes:- Offset: Vulnerable to missing or duplicate items when rows are inserted/deleted during paging: offsets shift, causing items to move between pages.- Cursor: Stronger consistency for forward-only scans: if cursor is based on immutable sort key (e.g., monotonic created_at + id), you won’t see duplicates/misses for stable snapshots. However, newly inserted items appearing before cursor won’t be seen (expected). For strict snapshot consistency, use DB-level cursors/transactions or materialized snapshots.Cacheability:- Offset: Highly cacheable for small page numbers (URL includes offset), CDN/cache keys are simple. Good for public, mostly-static lists.- Cursor: Less cache-friendly—opaque cursor makes responses unique per client and per time, reducing CDN hit rates. You can cache first-page responses and use short TTLs or embed cacheable list fragments.Operational considerations (SRE perspective):- Monitoring: Track page latency, DB CPU, index usage, and tail latency especially for high offsets. Alert on slow COUNT or OFFSET-heavy queries.- Throttling: Rate-limit deep paging; provide maximum allowed offset or total navigable items.- Backpressure: Enforce page size limits; prefer cursor API for continuous scrolls to reduce load spikes.- Migration: Moving from offset to cursor requires client changes; provide dual API, keep first-page compatible.- Data retention/compaction: If cursors reference physical positions, cleanup or reindexing can invalidate cursors—use logical keys (timestamps + ids).- Disaster recovery: Document how snapshot reads behave; for consistent exports offer snapshot endpoints or background export jobs rather than live deep paging.- SLA impact: Favor cursors for high-throughput endpoints to reduce DB load and improve p99 latency; use offset+CDN for low-change, read-heavy, cacheable endpoints.Recommendation: For high-traffic, dynamic data, prefer cursor-based pagination (immutable sort keys, bounded page size) with monitoring, rate limits, and first-page caching. Use offset only for simple, cache-friendly public lists or admin tools with small offsets.
EasyTechnical
62 practiced
List and explain the meaning and typical SRE reactions to these HTTP status codes in production: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error. For each, say what it signals to the client and how it should influence monitoring/alerts or incident triage.
Sample Answer
200 OK- Meaning to client: Request succeeded; response body (if any) contains the result.- SRE reaction: Normal. Monitor latency and success rate (p50/p95/p99). No alert on isolated 200s; alert if overall success rate drops below SLO or latency spikes.201 Created- Meaning to client: Resource created successfully; Location header may point to new resource.- SRE reaction: Normal for POST/PUT flows. Track creation rate and validate returned resource IDs. Alert if creation rate drops unexpectedly (possible upstream failures) or if creations succeed but subsequent read returns 404 (consistency issue).400 Bad Request- Meaning to client: Client sent malformed or invalid request (syntax/validation).- SRE reaction: Usually client-side. Monitor and log high-volume 400s (rate per endpoint, user-agent). If spike tied to recent client change or A/B test, notify product/dev teams; if originating from internal services, treat as possible regression and triage.404 Not Found- Meaning to client: Requested resource doesn't exist.- SRE reaction: Often expected (deleted/missing resources) but spikes matter. Monitor 404 rate per endpoint; high unexpected 404s after deployment indicate routing, config, or data migration issues—escalate to engineers.429 Too Many Requests- Meaning to client: Rate limit exceeded; client should back off.- SRE reaction: Signal of throttling or traffic surge. Monitor 429s and correlating traffic/quotas; adjust rate-limits, autoscaling, or inform clients. Alert when 429s cause user-impact beyond acceptable error budget.500 Internal Server Error- Meaning to client: Server-side failure; request couldn't be processed.- SRE reaction: Serious. Trigger alerts (high priority) when 5xx rate exceeds threshold or SLO breached. Triage: check service logs, recent deployments, resource exhaustion (CPU/memory), dependency failures, and circuit breaker states. Rollback/mitigate per runbook if widespread.General monitoring guidance:- Define SLOs (success rate, latency) and alert on symptoms (SLO breaches) not individual codes alone.- Correlate status code spikes with deployments, infra metrics, and dependency errors.- Use structured logs, per-endpoint metrics, and dashboards to speed triage.
EasyTechnical
104 practiced
You have an SLO that 99.9% of requests to a REST API must return 2xx or 3xx codes in a rolling 30-day window. Explain how you'd calculate error budget consumption using request metrics, discuss which 4xx and 5xx categories should be included or excluded, and describe how to treat planned maintenance or known client misbehavior.
Sample Answer
Calculation approach- Define window: rolling 30 days (sliding window updated continuously).- Denominator: total counted requests in that window after applying exclusions (maintenance, filtered client misbehavior).- Numerator (errors): count of requests judged “bad” in window.- Error budget consumption = numerator / denominator. For a 99.9% SLO, allowed error budget = 0.1% of requests in 30 days. If consumption ≥100% → burn.Practical implementation- Emit per-request metrics (status_code, route, client-id) to your metrics system (Prometheus, Datadog).- Compute rolling sums: bad_requests: increase by 1 for each classified error; total_requests: increase by 1 for all counted requests. Use rate() / sum over 30d or sliding-window counters.- Formula example: error_budget_used_pct = 100 * sum(bad_requests[30d]) / sum(total_requests[30d]).Which 4xx/5xx to include or exclude (policy + examples)- Always include all 5xx (500–599): server-side failures indicate reliability problems.- 4xx: classify deliberately, do not blindly include all. - Include 408 (Request Timeout) and 429 (Too Many Requests) when they reflect server/network limits or service throttling—these degrade reliability. - Exclude client-originated errors that represent invalid usage: 400 (bad payload), 401/403 (auth), 404 (unknown resource) IF they are caused by client mistakes or bad client versions. Exclude only when you can reliably attribute to client fault.- Make this a documented, version-controlled policy (e.g., “counting rules”) and log why a code is included/excluded.Planned maintenance and known client misbehavior- Planned maintenance: mark the time range as a maintenance blackout. Options: - Exclude requests during maintenance from both numerator and denominator (preferred) so availability isn’t penalized. - Alternatively, notify stakeholders and pause alerting; ensure maintenance windows are small and approved. - Record maintenance windows in the metrics pipeline so exclusions are reproducible/auditable.- Known client misbehavior (e.g., buggy client causing floods or malformed requests): - Filter those requests before they enter SLO calculations (apply deterministic rules: client-id, user-agent, IP ranges, request patterns). - If misbehavior is partial or intermittent, create a separate “client-error” metric and exclude it from denominator after review. - When filtering, keep an auditable record and monitor the volume — if large, treat as product/partner escalation rather than masking.Operational notes / best practices- Automate the counting rules and publish dashboards showing numerator, denominator, exclusions, and remaining error budget.- Alert on both error-rate spikes and rapid error-budget burn (e.g., 10% of budget consumed in 1 hour).- Review inclusion rules quarterly and after incidents to avoid gaming or hiding real outages.
MediumTechnical
70 practiced
Draft a deprecation plan for an old REST endpoint used by many clients: include how to announce deprecation (response headers, docs, mailing lists), a grace period, metrics to track client adoption, and rollback criteria from an SRE perspective to avoid breaking customers and to ensure observability during the transition.
Sample Answer
Situation: We're retiring a legacy REST endpoint used by many clients. Goal: deprecate without customer impact, ensure observability, and provide clear rollback criteria.Plan (high level)- Announcement channels (multi-modal, staggered): - Response headers: Add Deprecation: true, Sunset: <RFC-3339 date>, Link: "<new-docs-url>; rel=\"alternate\"". - API docs: Prominent banner, versioned docs with migration guide and sample code. - Email/mailing lists/Slack: Targeted notices to known client owners with migration steps and timelines. - Dashboard/Status page: Deprecation timeline and Q&A.Timeline & grace period- T0: Add Deprecation header + docs + client outreach.- T0 + 30 days: Soft enforcement window — log warnings, continue full service.- T0 + 90 days: Throttling phase for clients not migrated (rate-limit to reduced QPS).- T0 + 180 days: Sunset — return 410 Gone for remaining callers.Metrics to track (per-client + global)- Active client count calling deprecated endpoint (daily/weekly).- Request volume by client and endpoint (% of total traffic).- Error rates and latency for the endpoint and related services.- Migration progress: % calls to new endpoint vs old.- Health signals: 5xx spikes, increased retries, SLO/error budget burn.- Alerting thresholds: e.g., >5% of traffic still old after 120 days.Observability & dashboards- Create a deprecation dashboard: real-time client list, volume trends, error rates, latency histograms.- Correlate with dependent services (downstream queue lengths, DB load).- Log enriched with client-id, version, response-code, header flags to enable fast root-cause investigations.Rollback / mitigation criteria (SRE-runbook)- Abort sunset if: - Large client(s) still at >X% traffic and report inability to migrate after outreach. - System instability triggered by migration (e.g., new endpoint causes >2× error budget burn). - Unexpected surge in 5xx or latency correlated with deprecation actions.- Immediate actions on triggers: - Re-enable old endpoint fully (remove 410 / throttling). - Rollback any proxies/config that enforce deprecation. - Open incident, notify stakeholders, provide mitigation timeline. - Perform postmortem and adjust timeline/communication.Automation & testing- Automated scripts to compute per-client metrics, send reminders, and flip throttles.- Canary the throttling/sunset in a staging environment and a small client cohort first.Communication & support- Weekly migration reports to stakeholders.- Office hours / support channel for stuck clients.- Final cutover confirmation and post-sunset audit.This plan balances clear communication, measurable metrics, staged enforcement, and concrete rollback triggers to protect customers while retiring the endpoint safely.
Unlock Full Question Bank
Get access to hundreds of RESTful API Design and HTTP Fundamentals interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.