End-to-End Feature Design and Development Questions

The integrated "build a complete feature" interview format: taking one feature from user-facing flow through API design, backend logic, data model, and storage in a single coherent walkthrough. Tests the ability to connect the layers and make consistent trade-offs across them, rather than depth in any single layer.

EasyTechnical

32 practiced

Implement (outline) a RESTful API endpoint in Node.js/Express to create a todo item. Specify the request JSON schema, required validations, expected HTTP response codes, and how you would handle duplicate submissions, input sanitization, and returning newly created resource URL. No need for full source code—describe handlers and middleware.

Sample Answer

**Overview / approach**- POST /api/todos — accepts JSON, validates, sanitizes, deduplicates, creates and returns 201 with Location header.

**Request JSON schema**- Content-Type: application/json- Body: { "title": "string, 1-200 chars, required", "description": "string, optional, max 1000 chars", "dueDate": "ISO8601 date string, optional", "priority": "enum: low|medium|high, optional" }

**Validation & sanitization (middleware)**- Use express.json(), then a validation middleware using Joi or Zod:

javascript

// example with Joi
const schema = Joi.object({
  title: Joi.string().min(1).max(200).required(),
  description: Joi.string().max(1000).optional().allow(''),
  dueDate: Joi.date().iso().optional(),
  priority: Joi.string().valid('low','medium','high').optional()
});

- Sanitization middleware: trim strings, escape HTML (e.g., sanitize-html or DOMPurify on server), reject suspicious payloads.

**Handler flow**1. validate + sanitize -> 400 Bad Request with field errors if invalid.2. idempotency / duplicate handling: - Prefer idempotency-key header: store recent keys in Redis with request fingerprint; if repeated, return 200/201 with existing resource location. - If no key, detect duplicates by unique constraint (user_id + normalized title + dueDate). On DB unique violation -> 409 Conflict (or return existing resource).3. Create record in DB, return 201 Created with: - Location: /api/todos/{id} - Body: created todo JSON

**Expected HTTP codes**- 201 Created: success (Location header)- 200 OK: repeated idempotent request returning existing resource- 400 Bad Request: validation errors- 409 Conflict: duplicate detected without idempotency key- 500 Internal Server Error: unexpected failure

**Concurrency & security**- Wrap DB insert in transaction, rely on unique constraints to avoid race conditions.- Rate-limit endpoint, authenticate user (Bearer token), validate ownership.- Log and monitor duplicate/idempotency events.

This design balances UX (Location header + created payload), safety (sanitization/validation), and idempotency for client retries.

MediumSystem Design

34 practiced

Design a distributed API rate-limiting system that supports per-user and per-endpoint quotas, burst allowances, soft and hard limits, and exposes usage headers to clients. Explain implementation options (gateway-level, distributed store, token bucket), and how to operate it in a multi-region environment.

Sample Answer

**Problem clarification & goals**We need per-user + per-endpoint quotas, burst allowances, soft (warning) and hard (reject) limits, usage headers for clients, and global operation across regions with low latency and correctness.

**High-level architecture**- API Gateway (edge) enforces limits fast.- Distributed store for durable counters/leases (Redis CRDT or strongly consistent store per-region).- Central quota service for policy management and global sync.- Metrics & streaming for reconciliation.

**Implementation options**- Gateway-level token bucket: each gateway keeps an in-memory token bucket per (user, endpoint) for low-latency bursts. Refill rates defined by quota. - Pros: very fast, supports bursts. - Cons: needs synchronization across instances/regions for global limits.- Distributed store backing: use Redis (local replica per region) with atomic Lua scripts or Redis GCRA / leaky-bucket. Use a consistent key schema: quota:{user}:{endpoint}:{window}. - Strong option for hard/global limits; use TTLs for rolling windows.- Hybrid: enforce short-term burst locally with token buckets; periodically/atomically decrement global counters in Redis for long-term quota and hard limits. For soft limits, allow requests but return usage headers and warnings.

**Soft vs Hard**- Soft limit: gateway continues allowing but sets a header X-RateLimit-Warning and logs event to central service.- Hard limit: gateway rejects with 429 and standardized headers.

**Usage headers**Return headers on each response:- X-RateLimit-Limit: total allowed (user:endpoint)- X-RateLimit-Remaining- X-RateLimit-Reset: epoch seconds until reset- X-RateLimit-Warning: when soft exceeded

**Multi-region operation**- Keep per-region Redis for low latency; use asynchronous cross-region replication + CRDTs or a central strongly consistent store for billing-level quotas.- Use hybrid approach: local token buckets for immediate enforcement; on refill/periodic checkpoints, reconcile with global counters to prevent long-term overuse.- For strict global hard limits, route quota checks to a central authoritative service or use consensus (Paxos/RAFT) for critical accounts; accept slightly higher latency for those checks.

**Failure modes & trade-offs**- Stale local buckets can temporarily exceed global quota — mitigate with short checkpoint intervals and conservative local burst allowances.- Redis outage fallback: degrade to conservative defaults or use cached allowances.- Choose consistency vs latency: per-customer billing may need strong consistency; most APIs tolerate eventual consistency for rate counts.

**Operational notes**- Provide admin UI to set policies, per-customer overrides.- Instrument metrics (accepted/rejected, soft warnings) and alerts.- Test chaos scenarios and cross-region partitioning.

This hybrid design balances low-latency UX for bursts, accurate global quotas, and operational simplicity suitable for a full-stack developer to implement and iterate.

HardSystem Design

31 practiced

Design a complete observability plan for a new end-to-end feature spanning frontend and backend: what logs, metrics, and distributed traces to emit; how to instrument asynchronous or background flows; define SLIs/SLOs and alert rules; and propose dashboards and drill-down paths for on-call engineers.

Sample Answer

**Scope & assumptions**Feature: user uploads a document in SPA -> backend API -> async processing service (worker) -> storage + notifications. Stack: React frontend, Node/Express API, worker (Celery/Sidekiq), Postgres, S3.

**Observability goals**- Detect customer-visible failures & latency regressions- Fast root-cause (frontend vs API vs worker vs infra)- Alert with low noise, actionable runbooks

**Logs**- Frontend: structured client logs (level, event, user_id, request_id, url, browser, stack) sent to CDN/log-collector for errors and UX metrics (console.error with source map).- API/Workers: structured JSON logs (timestamp, service, env, level, request_id, user_id, endpoint, params_summary, error_code, stack).- Add context: correlation/request_id propagated via header X-Request-ID and logged everywhere.- Sample log fields: request_id, trace_id, span_id, user_id, feature_flag, queue_name, job_id.

**Metrics**- Business/SLI metrics: upload success rate, end-to-end median P95 latency (user action -> notification), processing queue length.- System metrics: API request rate, 5xx rate, latency histogram, worker concurrency, CPU/memory, DB connections, S3 error rate.- Names: feature.uploads.total, feature.uploads.success, feature.uploads.latency.p95_ms, feature.uploads.processing.queue_length

**Distributed Tracing**- Start trace at frontend (fetch/span on user action) include span for: upload request, auth, DB call, enqueue job, worker processing, S3 put, notification send.- Instrument async boundaries: attach trace_id and parent_span_id to job payload; worker continues trace by creating child span.- Capture attributes: user_id, request_id, job_id, sizes, error codes.

**Async/background flows**- Emit metrics per job: job.enqueue.time, job.start, job.duration_ms, job.failures.- Log retries with retry_count and backoff.- Correlate job to original request via request_id and trace_id.

**SLIs / SLOs & Alerts**- SLIs: - Success rate: uploads succeed (user gets success notification) — SLI = successful uploads / total uploads (target 99.9%). - E2E latency: P95 end-to-end <= 2s — SLO 99% of requests. - Processing lag: 95th worker job latency < 30s.- Alerts: - P0: upload success rate < 99.5% over 5m -> Pager - P1: E2E p95 latency > 3s for 5m -> Pager - P2: queue length > threshold (e.g., > 500) or worker errors rate > 1% -> Slack - Infra: host CPU > 85% across cluster -> Ops paging per existing runbook

**Dashboards & drill-down paths**- Top-level feature dashboard: - KPIs: success rate, E2E P50/P95, request rate, queue length - Heatmap of errors by component (frontend/API/worker)- Drill paths: 1. If success rate drops -> open errors panel -> filter by request_id/time -> jump to logs (all services) and traces for high-latency/failed traces. 2. If latency high -> view trace waterfall for slow spans -> check DB/S3/third-party latencies. 3. If queue growth -> inspect job duration distribution, worker CPU, error count; open recent failed job logs and trace/trace_id.

**Runbooks / actions**- For API 5xx spike: check recent deploy, rollback, check DB connection pool, run sample failing trace.- For worker backlog: scale workers, inspect poison jobs, retry policy.- For client JS errors: check sourcemap, blocklist, feature flag toggle.

This plan provides full end-to-end signal coverage, correlation via request_id/trace_id across async boundaries, clear SLIs/SLOs, actionable alerts and drill paths for on-call engineers.

MediumTechnical

56 practiced

As a senior full-stack developer, how do you evaluate architecture decisions for an end-to-end feature that must balance shipping quickly versus long-term scalability? Explain your decision framework, how you involve teammates and stakeholders, how you prototype or experiment, and how you document and communicate trade-offs.

MediumTechnical

43 practiced

Describe how to implement optimistic UI updates for a 'like' button in a React frontend. Detail immediate UI state changes, showing pending state, reconciling server responses, rollback behavior on failures, and backend design requirements for idempotency and conflict detection.

Sample Answer

**Approach (brief)** Implement optimistic UI by immediately toggling the local "liked" state and showing a pending indicator, send an API request with an idempotency key, then reconcile the server response: confirm, update counts, or rollback on failure. Backend must support idempotency, conflict detection and return canonical state.

**Frontend (React) — key steps**- Maintain local state: { liked: bool, likeCount: number, pending: bool, error: string }.- On click: set pending=true and flip liked/count locally, generate uuid idempotencyKey, fire PATCH/POST fetch.- When API returns success: set pending=false and apply server's canonical liked/likeCount.- On failure or conflict: set pending=false, rollback to server state, show toast/error.

Example code:

javascript

// React handler (simplified)
async function toggleLike(postId) {
  const idempotencyKey = crypto.randomUUID();
  const prev = { liked, likeCount };
  setState(s => ({ ...s, pending:true, liked: !s.liked, likeCount: s.likeCount + (s.liked ? -1 : 1) }));
  try {
    const res = await fetch(`/api/posts/${postId}/like`, {
      method: 'POST',
      headers: { 'Content-Type':'application/json', 'Idempotency-Key': idempotencyKey },
      body: JSON.stringify({ like: !prev.liked })
    });
    const json = await res.json();
    if (!res.ok) throw new Error(json.error || 'Server error');
    // reconcile with canonical server state
    setState(s => ({ ...s, pending:false, liked: json.liked, likeCount: json.likeCount }));
  } catch (err) {
    // rollback and show error
    setState(s => ({ ...s, pending:false, liked: prev.liked, likeCount: prev.likeCount, error: err.message }));
  }
}

**UI cues**- While pending show spinner or subtle opacity on button.- Disable repeated clicks until pending resolves (or dedupe via idempotency).

**Backend requirements**- Idempotency: accept an Idempotency-Key header; ensure repeated requests with same key produce same result and return previous response.- Conflict detection: validate request vs canonical state (timestamps, version numbers, or compare client-sent expected state). Return 409 with canonical state when mismatch.- Atomic update: increment/decrement counters and store per-user like records transactionally.- Response: always return canonical { liked: bool, likeCount: int, version?: int }.

**Trade-offs & notes**- Short optimistic window improves UX but requires careful rollback UX to avoid flicker.- Use event/versioning (ETag, version field) for stronger conflict handling in complex flows.

Unlock Full Question Bank

Get access to hundreds of End-to-End Feature Design and Development interview questions and detailed answers.

Join thousands of developers preparing for their dream job.