Design Authentication and Session System Design Interview Guide

← System Design Interview Preparation

This guide walks through Design Authentication and Session System the way you would in a backend or Java interview. The numbers are interview estimates. They help you show your thinking. They are not a production capacity plan.

1. Problem

Users sign up, log in, stay logged in, log out, and reset passwords. Other services need to know who is calling.

Example:

Email + password → hashed in DB
Session id in a cookie or access JWT + refresh token
/orders on the API gateway checks the session
Logout must actually stop access
Too many failed logins get rate limited

You are not building a full identity company (Okta). You are designing your auth service.

2. Functional Requirements / FR

Requirement	What it means
Signup / login	Create user, verify password.
Password hashing	Argon2/Bcrypt, unique salt.
JWT vs session	Pick one primary model; compare the other.
Refresh tokens	Short access, long refresh.
Session store	Revocable sessions in Redis/DB.
MFA	TOTP as a second step (brief).
Logout / revocation	Kill session or denylist.
Password reset	Time-limited emailed token.
Login rate limits	Stop stuffing.
OAuth / social	Brief: redirect, code, link account.

Out of scope: full SAML enterprise IdP, passkeys deep dive (mention as future).

3. Non-Functional Requirements / NFR

Requirement	Why it matters
Credential safety	Hashes, never logs of passwords.
Low login latency	Hash is slow on purpose; still < a few hundred ms.
Revocation	Stolen token should die.
Availability	Auth down = app down.
Audit	Failed logins, resets, new devices.

Interview line: hash passwords, short-lived access, revocable refresh/session, rate-limit login.

4. Back-of-the-Envelope Calculation

Traffic assumptions

50 million registered users
10 million DAU
2 logins/week/user average → ~3 million logins/day (many stay in session)
100 million authenticated API calls/day (session checks)
Read/write: validate is read-heavy; login is write (session create)

QPS

3,000,000 / 86,400 ≈ 35 QPS average
If peak is 5x, around 175 QPS of logins.

Session/JWT validate at gateway:

100,000,000 / 86,400 ≈ 1,160 QPS
If peak is 5x, around 6,000 QPS.

Storage

User row ~1 KB × 50M = 50 GB.

Sessions: 10M DAU × 500 bytes = 5 GB in Redis if one session each. Refresh tokens similar in DB.

Cache / memory

Redis sessions + login-attempt counters. JWKS tiny.

Servers

Login is CPU-heavy (hash). 175 QPS bcrypt might need several auth boxes. Validate JWT is cheap on the gateway. Interview estimates, not exact production numbers.

5. APIs

POST /v1/signup          { email, password }
POST /v1/login           { email, password, otp? }
POST /v1/logout
POST /v1/token/refresh   { refreshToken }
POST /v1/password/forgot { email }
POST /v1/password/reset  { token, newPassword }

GET  /v1/oauth/{provider}/start
GET  /v1/oauth/{provider}/callback

Gateway: Authorization: Bearer or cookie session_id.

Errors: 401 bad creds (same message for unknown user), 429 too many tries, 403 MFA required.

6. Data Model

`users`

user_id, email unique, password_hash, mfa_secret_encrypted nullable, status.

`sessions` (if session model)

session_id (random, hashed at rest), user_id, expires_at, user_agent, revoked.

`refresh_tokens`

id, user_id, token_hash, expires_at, rotated_from, revoked.

`login_events`

Append-only security log.

`reset_tokens`

Short TTL, single use.

Never store raw session ids in logs.

7. High-Level Design

Auth service owns credentials. Gateway enforces.

Authentication and Session architecture

Login checks the user database, then stores a session or issues tokens. Protected services validate the session store. Security events go out asynchronously.

Components:

User → API Gateway → Auth Service
User DB
Session Store
Refresh token flow
Protected services validate session/JWT
Queue → security alerts

Rate limit by IP + email.
Load user, verify hash.
Optional MFA.
Create session or issue access JWT (15 min) + refresh (30 days, rotated).
Emit login event.

Protected call: gateway validates JWT signature or Redis GET session.

8. Deep Dives

Password hashing

Bcrypt/Argon2 with work factor you can afford at peak QPS. Pepper in a secret manager optional.

JWT vs sessions

	Session id	JWT access
Revoke	Delete Redis	Need denylist or short TTL
Size	Small cookie	Bigger header
Lookup	Every request	CPU verify

Hybrid: JWT access + opaque refresh in DB is a strong interview answer.

Refresh

Rotate: new refresh, revoke old. Reuse of old refresh → steal detected, kill family.

MFA

After password, require TOTP. Backup codes hashed.

Logout

Delete session / revoke refresh. Access JWT lives until TTL unless denylist.

Password reset

Token 30 minutes, HTTPS link, invalidate sessions after reset.

OAuth

Redirect to Google, receive code, exchange, map sub to user_id, still create your session.

Rate limiting

5 failed / 15 min / email. CAPTCHA after that. Same as rate limiter.

9. Bottlenecks

Bcrypt CPU on stuffing attacks (limits first)
Redis session hot keys
Email blast on forgot-password (always return 200, rate-limit)
JWT none algorithm mistakes — pin algorithms

10. Tradeoffs

Choice	Upside	Downside
Pure JWT	Easy scale	Hard logout
Pure server session	Easy revoke	Redis on every call
Hybrid	Best of both	More moving parts

Pick: hybrid, hashed passwords, rotated refresh, login rate limits.

11. Failure Modes

Failure	Handling
Redis down	JWT still works until TTL; new logins fail or fall back to DB sessions
User DB down	Read replica for login if lag acceptable; else 503
Email down	Queue reset mail
Token leak	Rotate, revoke family, alert
Clock skew	JWT nbf/exp with leeway

12. Interview Answer in 10 Minutes

"I would put an auth service behind the API gateway.

Login volume is modest: a few million a day, tens of QPS, a few hundred at peak. The 6,000 QPS problem is validating calls. Passwords are Argon2/Bcrypt. I would issue a 15-minute JWT for APIs and a rotating refresh token stored hashed in the DB. Logout revokes refresh and deletes the session.

The gateway verifies JWT locally with cached keys. Login and reset are rate-limited. Failed logins go to a queue for alerts. MFA is TOTP after password for high-risk users.

I would not put raw cards or passwords in logs. I would not invent a custom hash."

13. Interview Talking Points

Hash + salt.
Short access, revocable refresh.
Rate-limit login.
Rotate refresh.
Same error for bad user/password.
Metrics: login success, failure, reset rate, p99 login, Redis errors.
Java Spring Security is a fair mention if you know it.

14. Follow-up Questions

Where is the session cookie scoped?
Secure, HttpOnly, SameSite, host-only.

SSO across apps?
Shared parent domain cookie or central auth + redirect.

Service-to-service?
mTLS or signed JWT with a different audience, not user passwords.

GDPR delete?
Anonymize user row; keep hashed audit if legally required.