Design a Scalable Node.js User Service

Clarify requirements

Before drawing boxes, ask about read/write ratio, peak QPS, latency targets, consistency needs, and whether profiles are public. A user service for login is different from a social graph. State assumptions aloud: for example, 50k registered users, 500 peak RPS, mostly reads of profiles after login.

API shape

Typical endpoints: POST /register, POST /login, GET /users/:id, PATCH /users/:id, POST /password-reset. Keep payloads small. Use stable IDs. Version the API if external clients depend on it. Return consistent error envelopes.

Auth and sessions

Describe access tokens (short-lived) plus refresh tokens (rotating) or server sessions in Redis. Keep Node instances stateless so you can horizontally scale. Store password hashes with a modern algorithm (bcrypt/argon2). Never log raw credentials.

Data and caching

Relational DB for users and credentials with unique indexes on email. Cache hot profile reads in Redis with a TTL and invalidate on update. Be explicit about cache stampede protection if a key is extremely hot. Separate PII concerns if compliance matters.

Scaling path

• Stateless app tier behind a load balancer
• Read replicas when read load grows
• Connection pooling sized to DB limits
• Rate-limit login to reduce credential stuffing
• Shard or partition only when a single primary cannot hold the working set

Observability and failure

Monitor login success rate, p95 latency, DB pool wait, cache hit ratio, and error budgets. For incidents, know whether to shed non-critical reads, serve stale cache, or disable expensive profile enrichments.

How to talk through it

Structure: requirements → API → data model → auth → cache → scale → risks. Mention one deep dive (for example indexing login by email, or refresh-token rotation) so the interview does not stay at buzzword level.