End to End Feature Development Questions

Covers the technical skills and system level thinking required to take a requirement and build a fully working feature across the entire stack. Topics include understanding user workflows and edge cases, designing user interfaces and user experience flows, authoring application programming interfaces and backend logic, creating data models and database schemas, implementing data access and queries, writing automated tests, handling error states and validation, ensuring performance and security, integrating with existing services, and deploying and monitoring the feature in production. Interview assessment focuses on practical design decisions, trade offs between simplicity and scalability, data consistency and transactional needs, testability, observability and monitoring, deployment and release strategies including continuous integration and continuous deployment, and collaboration with designers and other engineers to deliver a complete, reliable feature.

MediumSystem Design

32 practiced

Design an end-to-end 'Follow user' feature: list the API endpoints, sketch a simple data model for follows, explain concurrency control for follow/unfollow operations, describe how you would deliver realtime notifications to active followers, and propose strategies to maintain follower counts accurately at scale. Assume ~10M users and ~100k follow/unfollow ops per minute.

Sample Answer

**API Endpoints**- POST /users/{id}/follow — followerId in auth token. Creates follow.- DELETE /users/{id}/follow — unfollow.- GET /users/{id}/followers?cursor= — paginated list- GET /users/{id}/following?cursor=- GET /users/{id}/followers/count — fast counter- WebSocket/SSE endpoint: /realtime (auth)

**Simple data model**- Relational (Postgres) - follows (follower_id, followee_id, created_at, primary key (follower_id, followee_id)) - users (id, follower_count, following_count, ...)- Secondary indexes on followee_id and follower_id for lists.

**Concurrency control**- Idempotent APIs: INSERT ... ON CONFLICT DO NOTHING; DELETE returns 0/1.- Use DB transaction for strong correctness when adjusting counters: - Begin TX: insert/delete follow row, update users.follower_count = follower_count + 1 / -1 where id = followee_id and check affected rows.- For high throughput use optimistic eventual counters (below) and rely on DB uniqueness to avoid duplicates.- To avoid lost updates under high concurrency, use single-row updates (UPDATE users SET follower_count = follower_count + 1 WHERE id = X) — atomic in Postgres.

**Realtime notifications**- On follow success publish event to pub/sub (Kafka/RabbitMQ/Redis Streams): {type: "follow", follower_id, followee_id, ts}- Notification service consumes and: - Persists notification - Pushes to active clients via WebSocket cluster (use message broker + socket servers; identify client by user id) - For offline users, store and send push notifications (APNs/FCM) or email via background workers.

**Maintaining accurate follower counts at scale**- Hybrid approach: - Primary source: authoritative DB for rare strong-consistency checks. - Fast path: in-memory distributed counters (Redis INCR/DECR with shards) for read-heavy endpoints. - Periodic reconciliation: background jobs aggregate actual follow rows and correct drift (daily/hourly); run on hot users more frequently. - Use monotonic IDempotent deltas published to event log so counters can be rebuilt (stream processing with Kafka + stateful processors). - For extreme scale, use CRDT counters or per-shard counters with periodic merge.

**Notes / Trade-offs**- Synchronous DB updates ensure correctness but limit throughput. Using async counters + reconciliation improves latency at cost of eventual consistency.- WebSocket scaling requires sticky routing or a distributed pub/sub to deliver events to whichever socket server holds the user connection.

HardSystem Design

31 practiced

Design an end-to-end collaborative 'shared documents' feature that supports real-time editing across devices and offline edits. Compare Operational Transformation (OT) and CRDTs for conflict resolution, propose a storage and sync model across multiple regions, define security/permission checks, and outline an incremental rollout and testing strategy.

Sample Answer

**Overview & goals**Design a shared-docs system that supports low-latency real-time editing, offline edits with guaranteed convergence, multi-region availability, fine-grained permissions, and safe incremental rollout.

**High-level architecture**- Clients (web/mobile) run an editing engine and local persistence (IndexedDB).- Real-time layer: WebSocket/HTTP2 to regional gateway → collaboration service.- Durable store: regional write-master + cross-region replicated object store (S3/Blob) + metadata DB (CockroachDB/Spanner).- Background sync workers for cross-region replication and garbage collection.

**OT vs CRDT (comparison & choice)**- OT: compact ops, well-known for text editors, requires central transform server and preserved operation history; non-trivial for multi-site offline edits and many concurrent editors.- CRDTs: strong eventual consistency, peer/edge-friendly, easier offline merges—higher metadata overhead (tombstones, identifiers).- Choice: Use a hybrid—CRDT (sequence-based, e.g., RGA or Logoot-Undo) on client for offline/resilient merges and conflict-free convergence; use server-side compaction to reduce tombstones.

**Storage & sync model**- Client persists local CRDT state + op-log to IndexedDB; sends ops to regional gateway.- Regional gateway persists ops to durable append-log and applies to regional materialized view.- Cross-region: async replication of compacted snapshots + op-log; causal vector clocks to ensure ordering.- Periodic snapshotting and server-side compaction to reduce metadata; clients can bootstrap from nearest region.

**Security & permissions**- Auth via OAuth2/OIDC; clients receive short-lived JWTs with doc-scoped claims.- Permission checks: - Client enforces UI-level permission (read/write/comment). - Each op signed and authorized at gateway using token and ACL lookup in the metadata DB. - Server rejects unauthorized ops; audit logs written immutable.- Encryption: TLS in transit; at-rest encryption per-region; optional E2EE for private docs with client-managed keys.

**Incremental rollout & testing**- Start with single-region, read-only collaborative preview.- Canary real-time for internal teams, then small % of users.- Tests: unit (CRDT invariants), integration (multi-client sync), chaos testing (network partitions, clock skew), load testing (ops/sec), correctness fuzzing.- Monitoring: op lag, conflict rate, replication lag, error rates; automatic rollback on SLA breaches.

**Edge cases & trade-offs**- CRDT metadata growth vs. OT server complexity; compaction solves growth at cost of occasional client resync.- Latency vs. strong ordering: prefer low-latency local edits with causal guarantees.

This approach fits full-stack responsibilities: client CRDT implementation, gateway auth and op persistence, server compaction, and deployment/observability.

MediumTechnical

33 practiced

Compare session management options for a multi-region web application: sticky sessions, centralized session store (e.g., Redis), and token-based sessions (JWT). Evaluate trade-offs for latency, failover, token revocation, performance, and data residency compliance.

Sample Answer

**Overview — options**- Sticky sessions (load-balancer affinity)- Centralized session store (Redis/Memcached)- Token-based sessions (JWTs, opaque tokens)

**Latency**- Sticky: lowest intra-region latency (requests hit same server). Cross-region requests still higher if client far from server; cross-region failover can add latency.- Redis: extra network hop to store; placing read/write replicas regionally reduces latency but adds complexity.- JWT: minimal server latency — validated locally; ideal for read-heavy APIs.

**Failover / Availability**- Sticky: poor — if instance dies, session lost unless replicated.- Redis: better with clustered replication; single-region Redis is a SPOF unless multi-region replication configured.- JWT: resilient — tokens survive server failures; need valid key distribution for verification.

**Token Revocation & Security**- Sticky: server controls session invalidation easily.- Redis: immediate revocation by deleting session.- JWT: hard to revoke before expiry; requires short TTL + revocation list (stored centrally, adds latency) or rotating keys.

**Performance & Scalability**- Sticky: simple but scales poorly for auto-scaling and rolling deploys.- Redis: centralizes load; performant if sharded/clustered; costs network I/O.- JWT: scales best for stateless services; beware token size and replay protection.

**Data Residency / Compliance**- Sticky: session data stays where instance runs; risky if cross-border routing occurs.- Redis: must provision regional clusters or encrypt and shard to comply.- JWT: stores claims client-side — avoid sensitive PII in token; sign/encrypt and control issuance per region.

**Recommendation (Full‑Stack)**- Prefer JWTs for scalable, low-latency APIs with short TTLs and central revocation mechanism for critical flows; use regional Redis for server-side sessions when you need easy revocation, small session footprint, or must store sensitive state to meet compliance. Avoid sticky sessions for global, highly-available apps.

EasyTechnical

62 practiced

If tasked to split a monolith's 'search' functionality into services, describe the criteria you'd use for decomposition, safe first steps to extract the service, how to handle data ownership and synchronization, and integration patterns to keep the monolith functional during the transition.

EasyBehavioral

56 practiced

Tell me about a time when you owned and delivered an end-to-end feature across frontend and backend. Describe the requirement, how you collaborated with designers and product managers, key technical decisions and trade-offs you made, how you validated the feature (tests/metrics), and the outcome or learnings from the delivery.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.