MediumTechnical

83 practiced

Design a consistent error response format for an API used by multiple front-end and mobile clients. Specify fields (HTTP status, error code, message, details, user-facing vs developer-facing info). Provide an example JSON error response for a validation failure where both 'email' and 'password' fields are invalid.

Sample Answer

**Design goals**- Consistent, machine-parseable, human-friendly across web + mobile- Separate user-facing text from developer diagnostics- Stable error codes for client logic, HTTP status for transport semantics- Include correlation id for tracing

**Fields**- http_status (number): HTTP status code returned- error_code (string): stable, namespaced machine-readable code (e.g., AUTH.VALIDATION)- message (string): short user-facing summary (safe to display)- details (array): field-level errors; each item: { field, code, message } (user-facing)- debug (object, optional): developer-facing diagnostics (stack, trace_id, internal_code) — not shown in production to end users- retryable (bool): whether client can retry automatically- timestamp (ISO8601)

Example: validation failure for email + password

json

{
  "http_status": 400,
  "error_code": "AUTH.VALIDATION",
  "message": "There were validation errors with your submission.",
  "details": [
    {
      "field": "email",
      "code": "INVALID_EMAIL_FORMAT",
      "message": "Enter a valid email address."
    },
    {
      "field": "password",
      "code": "PASSWORD_TOO_SHORT",
      "message": "Password must be at least 8 characters."
    }
  ],
  "retryable": false,
  "timestamp": "2026-03-02T12:34:56Z",
  "debug": {
    "trace_id": "req-123456",
    "internal_code": "VAL-1002"
  }
}

Reasoning: clients use http_status + error_code for control flow; UIs show message/details; debug aids engineers and logs but should be gated by environment.

HardTechnical

109 practiced

Design a distributed, high-performance rate limiter for an API used globally. Discuss token-bucket vs leaky-bucket semantics, how to implement consistency across regions (centralized store vs local approximations), and the data structures you would use in Redis or another datastore to track usage. Also describe how to expose rate-limit headers to clients.

Sample Answer

**Approach overview**I’d build a regionally distributed rate limiter at the API gateway layer: enforce locally for low-latency, optionally consult a centralized/global store for strict global limits. Use token-bucket semantics for burstiness and leaky-bucket (fixed-rate drain) when you need even spacing.

**Token-bucket vs Leaky-bucket**- Token-bucket: allows bursts up to bucket capacity; refill rate = sustained rate. Good for user experience.- Leaky-bucket: enforces a steady output rate; simpler, smoother. Use when backend must not see bursts.

**Consistency across regions**- Strict global limits: centralized store (Redis Cluster / managed Redis with low-latency WAN links); every request checks global counter—higher latency.- Hybrid (practical): give each region a quota slice from global pool (e.g., token allotments per-minute). Local enforcement fast; background sync or refill from global store. Handle overspend by reconciling periodically or on hit.- Eventual consistency: allow slight violations; acceptable if SLA tolerates short bursts.

**Data structures & implementation in Redis**- Fixed-window: INCR with EXPIRE on key "rl:{user}:{window_ts}" — simple but boundary spikes.- Sliding window (accurate): Sorted Set per user storing timestamps; ZREMRANGEBYSCORE + ZCOUNT for window. Use Lua to make ops atomic.- Token-bucket: Hash storing {tokens, last_refill_ts, rate, capacity}; use Lua to compute refill, consume tokens atomically.Example Lua token consume (atomic):

lua

-- KEYS[1] = key, ARGV: now, tokens_needed, refill_rate, capacity
local key = KEYS[1]
local now = tonumber(ARGV[1])
local need = tonumber(ARGV[2])
local rate = tonumber(ARGV[3])
local cap = tonumber(ARGV[4])
local data = redis.call("HMGET", key, "tokens", "last")
local tokens = tonumber(data[1]) or cap
local last = tonumber(data[2]) or now
tokens = math.min(cap, tokens + (now - last) * rate)
if tokens >= need then
  tokens = tokens - need
  redis.call("HMSET", key, "tokens", tokens, "last", now)
  return 1
else
  redis.call("HMSET", key, "tokens", tokens, "last", now)
  return 0
end

**Operational considerations**- Use Lua for atomicity.- Shard keys to avoid hot keys; use per-user or per-API keys.- TTL on keys to reclaim memory.- Monitor metrics and add circuit-breakers when Redis is unavailable (fallback to local soft-limits).

**Exposing headers to clients**Return standard headers each response:- X-RateLimit-Limit: total allowed in window- X-RateLimit-Remaining: remaining tokens/requests- X-RateLimit-Reset: seconds until window or next refill- When blocked, return 429 with Retry-After (seconds) and same headers.

This design balances latency, accuracy, and operational simplicity for a global API used by a full-stack team.

HardSystem Design

85 practiced

Design a secure file upload API for user avatars. Requirements: prevent malicious uploads, support large files via chunked uploads, avoid storing files on application servers, and provide URLs for direct upload to object storage. Describe steps for pre-signed URL generation, server-side validation, virus scanning, and how to handle aborted uploads.

Sample Answer

**Overview — goals**I would design an API that issues time-limited presigned URLs for direct-to-object-storage uploads (supporting chunked/multipart), enforces server-side validation and post-upload antivirus scanning, never buffers full files on app servers, and reliably cleans up aborted or infected uploads.

**Presigned URL generation (flow)**- Client requests upload with metadata: user_id, filename, content_type, expected_size, checksum.- Backend authenticates user, enforces quotas and file-type/size policy.- Backend records an upload intent in DB: upload_id, user_id, allowed_types, max_size, status=INIT.- Backend uses cloud SDK (IAM role with minimal s3:PutObject/multipart permissions) to generate time-limited presigned URLs: - For simple uploads: single presigned PUT for the object key like avatars/{user_id}/{upload_id}/{filename} - For large files: initiate multipart, generate presigned URLs per part and return uploadId + part URLs.- Return upload_id, URLs, expiration and required headers (content-type, ACL).

**Client-side behavior**- Upload directly to storage using presigned URLs, send required headers (e.g., content-type, Content-MD5).- For multipart: upload parts in parallel, then call backend to complete multipart with part ETags.

**Server-side validation & acceptance**- On upload completion, client calls backend to mark complete (includes file checksum, size, part ETags).- Backend verifies: - The object exists at expected key and size via storage HEAD. - Checksum/ETag matches (for multipart compute combined ETag or verify via server-side copy+checksum if supported). - Content-type matches allowed list and magic bytes inspected server-side (see scanning).- If validation passes, set DB status=UPLOADED and enqueue virus-scan job.

**Virus scanning**- Use blob scan workers that stream directly from object storage (no app-server temp saves) into a scanning engine (ClamAV or commercial scanner) via signed read URLs.- Scanner streams object, inspects magic bytes, and returns verdict.- On clean: set status=VERIFIED and generate a short-lived CDN-backed public access URL or store object with restricted ACL and issue a secure CDN URL / token.- On infected: set status=REJECTED, move object to quarantine bucket with restricted access, notify user, and trigger audit/logging. Optionally keep ETag for forensic.

**Handling aborted/partial uploads**- Track multipart sessions and last-seen activity timestamps in DB.- Use lifecycle rules in storage to automatically expire incomplete multipart uploads after N days (plus ensure server-initiated abort on detection).- Periodic cleanup job: find stalled upload intents > TTL and abort multipart via SDK, delete partial objects, set status=ABORTED.- Client retry: support resumable uploads by reusing upload_id and remaining part URLs within presigned expiration; if expired, backend issues new presigned URLs after verifying owner and current state.

**Security & best practices**- Principle of least privilege IAM roles; presigned URLs scope to exact key and expire quickly.- Enforce content sniffing (magic bytes), size limits, and allowlist extensions.- Use HTTPS everywhere; sign API requests (JWT/OAuth).- Audit logs for presigned URL issuance, scans, and finalization.- Rate-limit upload initiation and enforce per-user quotas to prevent abuse.- Serve avatars via CDN with tokenized URLs or signed cookies to avoid exposing storage directly.

This design keeps app servers out of the data path, supports large files via multipart, provides robust validation and scanning, and handles aborted uploads with lifecycle and server-side cleanup.

HardSystem Design

66 practiced

You're evolving an API and must coordinate schema changes that affect both the database and public API payloads. Propose a safe migration strategy that minimizes downtime and client breakage: include database migration order, backward-compatible API layer changes, feature flags, and client rollout coordination.

Sample Answer

**Clarify goals & constraints**- Preserve availability, avoid client breakage, support rollback, minimize coupling between DB and public API change windows.

**High-level strategy (expand → migrate → contract)**1. Expand DB schema first (add columns/tables/indexes nullable or with defaults).2. Deploy API that writes both old and new fields (dual-write) and reads old field by default.3. Backfill/transform existing rows into new schema asynchronously.4. Switch API read path to new schema behind a feature flag.5. Once stable, stop writing old fields, remove deprecated API fields and then drop old DB columns after a safe waiting period.

**Database migration order & details**- Use non-blocking DDL (add nullable column, create indexes concurrently).- Small, idempotent migration scripts run via a migration tool (Flyway/Liquibase) with retries and logging.- Backfill via job queue with rate limiting to avoid DB overload; mark progress in a control table for resumability.- Only drop columns after monitoring shows zero reads/writes to old fields for N days.

**API layer changes**- Add new fields to responses but keep old fields until client opt-in; prefer additive changes (never change semantics).- Implement versioned endpoints or use media-type/version headers for major breaking changes.- Dual-read/dual-write logic behind feature flags so you can switch reads independently of writes.- Validate inputs and provide helpful deprecation warnings in response headers/body.

**Feature flags & rollout**- Use targeted flags (percent rollout, user groups) to flip read path to new schema.- Start internal QA → canary (10%) → gradual ramp (50% → 100%) with automated smoke tests and metrics gating.

**Client coordination**- Publish migration timeline, API contract changes, and SDK updates in developer portal and mailing lists.- Provide migration guides, code samples, and versioned SDKs; keep older SDKs working until deprecation deadline.- Offer compatibility endpoints or header that indicates server-supported versions.- Communicate deprecation windows (e.g., 90/60/30 days) and require client opt-in for breaking changes.

**Rollback & monitoring**- Monitor error rates, latency, business metrics, and schema usage via dashboards and alerts.- Feature flags enable fast rollback to prior behavior without DB changes.- Maintain runbooks for rollback and for final column removal.

This approach minimizes client disruption by separating schema changes from traffic shifts, using feature flags for controlled rollout, and coordinating clients with clear timelines and tooling.

MediumBehavioral

77 practiced

Behavioral: Tell me about a time when you had to design or refactor an API endpoint that multiple teams depended on. Explain the steps you took to gather requirements, communicate changes, ensure backward compatibility, write tests, and how you handled disagreements with stakeholders. Use the STAR format.

RESTful API Design and HTTP Fundamentals Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank