Full Stack Architecture and Feature Design Questions

Ability to design complete features considering frontend UX, backend API design, database schema, and data flow. Understanding of separation of concerns and communication between layers. API-first design thinking. Discussing trade-offs (e.g., complex queries on backend vs post-processing on frontend). Designing for extensibility and maintainability.

MediumSystem Design

83 practiced

Design a cache invalidation strategy for content edited via an admin panel that must reflect on public pages served from a CDN and on API endpoints cached by application servers. Describe how to invalidate or refresh caches at the edge, application layer, and downstream search indices while minimizing stale windows and avoiding origin overload.

Sample Answer

**Clarify requirements & constraints**- Editors change content via admin panel; public pages are served from a CDN and APIs are cached in app servers; goal: reflect edits quickly, minimize stale windows, avoid origin overload and cache stampedes.

**High-level strategy**- Use cache-tagging (surrogate-keys) + targeted CDN purges, coordinated app-layer invalidation, and asynchronous search-index updates via a queue.

**Edge (CDN)**- Assign surrogate-keys per content entity (e.g., content:1234, author:56, collection:news).- On edit, issue a targeted purge/invalidation by surrogate-key (not global purge). If provider lacks surrogate-keys, purge specific paths.- Use “soft purge” / stale-while-revalidate when supported so requests still served while CDN fetches updated origin.- Rate-limit and batch purge requests (accumulate keys for 200–500ms window) to reduce API calls.

**Application layer (API caches)**- Cache using tag-aware store (Redis with tag sets) or cache keys derived from entity version (ETag/versioned key).- On edit: - Update origin datastore (DB). - Invalidate Redis keys for affected tags (lookup tag -> key set). - Use short TTL for derived lists and longer TTL for heavy reads; employ background refresh (refresh-ahead) to warm cache. - Prevent stampede with per-key locks or singleflight pattern.

**Search indices**- Push index-update messages to a durable queue (e.g., Kafka, SQS).- Consumers perform incremental updates; for major edits, schedule full reindex of affected subset.- Acknowledge edits quickly to admin UI while indexing proceeds; show “indexing in progress” where strict consistency needed.

**Avoid origin overload**- Batch & debounce invalidations and index tasks; exponential backoff on retries.- Stagger TTL expirations for related objects to avoid synchronized cache misses.- Use warm-up workers to prefetch hot objects after purge instead of letting traffic spike origin.

**Observability & safety**- Metrics: purge success, origin QPS, cache hit ratio, indexing lag.- Fall-back: rate-limited full purge for emergencies; admin UI confirmation for destructive operations.

Example: edit content 1234 -> enqueue job: { id:1234, tags:[content:1234,collection:news] } -> worker: 1) update DB 2) CDN purge by surrogate-key batch 3) invalidate Redis keys via tag lookup 4) push index update. This minimizes stale windows while batching work to protect origin.

MediumSystem Design

49 practiced

You need to deploy a backend change that introduces a new non-nullable column required by a new frontend feature. Describe a zero-downtime migration and deployment plan across services and regions: schema steps (expand-contract), data backfill, feature flags to gate behavior, incremental rollouts, and rollback strategies in case of issues.

HardTechnical

44 practiced

Design a GraphQL API for a large product catalog used by various clients with differing data needs. Discuss schema design, how to mitigate N+1 resolver problems (e.g., dataloader/batching), caching strategies for GraphQL responses or fields, pagination for nested collections, and field-level authorization. Include examples of resolver design to avoid expensive DB calls.

Sample Answer

**Design overview**- Use a schema that separates Product, Variant, Price, Inventory, Category with normalized types and optional payloads (e.g., Product.details: ProductDetails) so clients request only needed fields.- Expose multiple entry points: product(id), products(filter, first, after), search(query, paging).

**Schema & pagination**- Use cursor-based pagination for lists and nested collections (Relay-style edges/node). For heavy nested lists (reviews, relatedProducts) require explicit args to avoid accidental deep fetches.

**Mitigating N+1**- Use DataLoader on a per-request context to batch and cache DB calls.- Always design resolvers to return ids when possible and let parent-level loaders fetch related data in batches.

Example resolver using DataLoader (Node/TypeORM):

javascript

// context.js
const productLoader = new DataLoader(ids => db.products.whereIn('id', ids));
const inventoryLoader = new DataLoader(ids => db.inventories.whereIn('product_id', ids));
return { loaders: { productLoader, inventoryLoader } };

// resolver
Product: {
  inventory: (product, _, { loaders }) => loaders.inventoryLoader.load(product.id)
}

Batching query uses WHERE IN and projects only requested columns.

**Caching**- CDN + persisted queries for full response caching of common queries.- Field-level cache: cache expensive fields (price-calculation, recommendations) in Redis with short TTL and cache keys including user/context.- Use cache-control headers and GraphQL response signatures to allow safe caching.

**Field-level authorization**- Implement schema directives (@auth(roles:["admin"]) or field middleware) evaluated per-request using user context.- Example: resolve product.price only if hasPermission(user, 'view_price'); otherwise return null or mask.

**Resolver best practices**- Avoid per-item SELECTs; use joins or batched loaders.- Use projection to select only requested fields (look at GraphQLResolveInfo).- Return references (ids) from parent resolvers to let child resolvers batch.- Monitor with tracing to find remaining N+1 hotspots.

This design balances flexibility for clients, performance at scale, and fine-grained security.

HardSystem Design

44 practiced

You must roll out a complex feature requiring coordinated backend API changes, DB schema updates, and new frontend behavior while some clients (mobile apps) may lag in updates. Describe a safe migration pattern including backward-compatible APIs, feature flags, staged deployments, data migrations, and rollback procedures that allow forward and backward compatibility during the transition.

Sample Answer

**Clarify goals & constraints**- New feature requires API + DB + frontend changes; some mobile clients lag and cannot immediately handle breaking changes.- Aim: zero-downtime, forward/backward-compatible rollout with safe rollback.

**High-level pattern**1. Backward-compatible API design - Add new endpoints or optional fields; avoid removing or changing semantics. - Use feature negotiation header or versioned endpoints (e.g., /v2/*) only when necessary.2. Schema migration strategy - Expand schema non-destructively: add nullable columns, new tables, or JSON columns. - Use “expand → backfill → switch → cleanup”: - Expand: add columns with defaults NULL. - Backfill: background job populates new columns. - Switch: change services to read new columns behind feature flags. - Cleanup: drop old columns after clients upgrade.3. Dual-write / dual-read (shadowing) - For a transition window, services perform dual-write to old and new schema. - During switching, support dual-read where server prefers new column but falls back to old.4. Feature flags & gating - Use per-client flags (by user, platform, app-version) to enable new behavior selectively. - Gate API responses and UI behavior behind flags; do not send fields clients can't handle unless flagged.5. Staged deployments - Canary backend deploy to small subset; monitor errors/latency. - Gradually increase rollout and enable flag for cohorts (internal users → beta testers → 10% → 50% → all). - For mobile: enable server-side behavior only for client versions that advertise capability (via user-agent or version header).6. Data migration considerations - Run idempotent, resumable background jobs with batching and rate limits; track progress in a migration table. - Validate with checksums/sample comparisons; use feature flags to toggle reading migrated data.7. Monitoring & rollback - Instrument API logs, error rates, business metrics, and mobile crash reports; create dashboards and alerts. - Rollback plan: - Flip feature flag off (instant rollback of behavior). - Re-deploy previous backend if needed (stateless changes first). - Stop background writes to new schema and continue reading old until safe. - Ensure migrations are reversible where possible; if destructive, delay cleanup until clients upgraded.8. Example flow (concrete) - Add new nullable column `new_setting`. - Deploy backend that writes both `setting` and `new_setting` and serves `new_setting` only if client-version >= X or flag on. - Backfill `new_setting` for old rows. - Enable flag progressively; once >99% clients support, switch to read-only `new_setting` and schedule cleanup.9. Trade-offs - Dual-write increases complexity and temporary storage cost. - Longer migration window keeps compatibility but delays cleanup.

I would implement this with feature-flag tooling (LaunchDarkly/Unleash), migration jobs in worker queues, strict API version checks for mobile, and automated rollback playbooks tested in staging.

HardSystem Design

58 practiced

Design a comprehensive A/B testing pipeline: deterministic user assignment/bucketing, experiment configuration storage, client and server exposure tracking, event collection for metrics, an analysis pipeline for deciding winners, and rollout of winning variants. Discuss cross-device identity, statistical considerations, powering real-time guardrails, and how to safely end or roll back experiments.

Sample Answer

**Clarify requirements & constraints**- Primary goal: safe, measurable feature experiments with deterministic bucketing, near‑real‑time guards, and safe rollout/rollback.- Constraints: low latency for client decisions, GDPR/PIP A compliance, multi-device users, and ability to run many concurrent experiments.

**High-level architecture**- SDKs (web/mobile) + Decision API + Experiment Config store + Event ingestion (Kafka) + Metrics/analysis pipeline (Spark/Beam) + Real‑time guardrails (streaming alerts) + Feature rollout service.

**Deterministic bucketing**- Use stable hash(user_id + experiment_id + salt) → float [0,1). Map to variant ranges. For anonymous users, use device_id or session_id and reassign when identity is merged.- Store assignment key/version in cookies/localStorage and server-side user profile to maintain consistency across devices after identity resolution.

**Experiment configuration**- CD-ed config in a central store (e.g., DynamoDB/postgres + S3 for versions). Fields: experiment_id, variants, allocation, start/end, preconditions, metrics, exposure rules, safety thresholds, hash_salt, active_flag.- API to fetch configs; clients cache with TTL and fallback to server decision.

**Exposure tracking (client & server)**- Two-step: Decision exposure (when SDK chooses a variant) and Treatment exposure (when treatment actually rendered).- Emit deterministic exposure events immediately to ingestion with metadata: experiment_id, variant, user_id, device_id, timestamp, client_version, context.- Server-side: log any server-rendered decisions and conversions from backend flows.

**Event collection & enrichment**- Ingest via a low-latency pipeline: client → API gateway → Kafka. Enrich with user profile, device, geo in stream processors. Persist raw events (parquet) and aggregated summaries.

**Analysis pipeline & statistical considerations**- Primary metrics predeclared: numerator, denominator, guard metric(s).- Use incremental analysis: daily batch (Spark) and streaming approximations.- Statistical methods: - For final decisions: use pre-specified hypothesis tests (bootstrap or t-test for continuous; Poisson/binomial for rates) with confidence intervals. - Control false discovery: Bonferroni or BH when running many experiments. - Support sequential testing (alpha spending / Bayesian posterior or MPR) for frequent looks; avoid naive peeking. - Report effect size, CI, risk of type S/M errors, and power; require minimum sample and duration.

**Real-time guardrails**- Streaming checks compute lift and safety metrics (error rates, latency, crash rate) with short windows (1–5m). Use exponentially weighted aggregations and alert when thresholds exceeded.- Automatic kill switch: if safety metric breaches a critical threshold, trigger circuit breaker to revert relevant users to control (via feature flag service) and notify on-call.

**Rollout & rollback**- Rollout: promote variant to traffic percentage increments using same bucketing salt; toggle config active_flag and allocation. Use canary cohorts (internal users, 1%, 5%, 25%, 100%).- Safe rollback: config versioning enables immediate revert; ensure idempotent server behavior. Run post-mortem on any auto-kill.

**Cross-device identity**- Use deterministic assignment tied to persistent identity when available. On identity merge, prefer server-side canonical assignment and reconcile exposures by mapping device events to unified user_id. For privacy, keep anonymous assignments until opt-in.

**Operational concerns**- Latency: prefer client-side decisions for UI but validate server-side exposures.- Telemetry correctness: deduplicate events by event_id; implement backfills.- Privacy & compliance: hash IDs, respect do-not-track; store PII separately.

**Example flow**- User loads page → SDK fetches config → hash(user_id, exp_id, salt) → variant A → emit exposure event → user converts → event ingested → streaming computes lift → if safe, continue; if guard triggers, rollback via feature flag.

This balances full‑stack responsibilities: implement SDK + decision API, ensure reliable event pipelines, and build analysis and operational tooling to run experiments safely.

Unlock Full Question Bank

Get access to hundreds of Full Stack Architecture and Feature Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.