Katkat
Back

Design signup and login service

BridgeSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question evaluates understanding of authentication system design, secure password storage practices, API endpoint and request/response modeling, database schema design, and session or token-based login state management.

Design a basic email/password authentication service that supports user sign-up and login. You may not rely on third-party identity providers (no OAuth/OIDC, no social login). Large-scale traffic is out of scope — assume a single relational database is enough — but the bar is a clean API design, a sound database schema, and correct, secure handling of credentials and login state.

Your design should cover:

  • The main functional requirements for registration and login.
  • API endpoints and their request/response shapes.
  • Database tables and key fields.
  • How passwords are stored securely.
  • How login state is managed after a user authenticates.
  • Basic input validation and the important failure cases.

Constraints & Assumptions

  • Scale is out of scope. A single stateless app server plus one relational database (e.g. Postgres) is acceptable; no sharding, no distributed session store required (mention where they would plug in).
  • No third-party auth. Email + password only; you own the credential lifecycle.
  • Transport is HTTPS; assume TLS terminates in front of the service.
  • The security bar still holds: correct password hashing, no user enumeration, and basic brute-force throttling are expected even though scale isn't.
  • You may declare features explicitly out of scope (email verification, password reset, MFA, account deletion / GDPR flows) as long as you note where each would attach.

Clarifying Questions to Ask

  • Is the client a browser (so cookies are viable) or a native/mobile/service client (so a bearer token in the body/header is needed) — or both?
  • Should signup auto-log-in the user (issue a session immediately), or just create the account?
  • How important is anti-enumeration for this product? It changes the signup response shape (generic "check your inbox" vs an explicit 409).
  • What session lifetime is acceptable, and do we need "log out from all devices"? That influences opaque-token vs JWT.
  • Are there password-policy requirements (minimum length, breached-password checks) we must enforce?

Hints

Hint 1

Decompose it: This is a CRUD-plus-security problem, not a scaling problem. Split it into five concerns and address each cleanly: (1) the data model, (2) the API surface, (3) password storage, (4) session/login-state management, (5) validation and abuse. The interviewer is grading correctness and security judgment, not throughput.

Hint 2

Password storage: Passwords must be **salted and slow-hashed** — never stored in plaintext and never run through a fast general-purpose hash (MD5/SHA-1/SHA-256). Name a memory-hard, deliberately-slow algorithm and explain what the salt and cost parameters buy you.

Hint 3

Login state: After login the server hands the client a credential. Be ready to compare the two standard options — an **opaque server-side session token** vs a **signed self-describing token (JWT)** — and justify your pick on *revocation* and *control*, which matter more than per-request latency when scale is out of scope.

Hint 4

The subtle failure case: The trickiest correctness detail is **user enumeration**: a login or signup response must not reveal whether an email is registered, and that includes closing the *timing* side channel, not just the response body.

Follow-up questions

  • How would your design change if you later needed **"log out from all of my devices"** and a global "force re-login" after a password change?
  • Where exactly would **email verification** and **password reset** flows attach to this schema and API, and what new tokens/tables would they need?
  • If per-request session lookups became a real bottleneck, what would you change — and what would you give up by switching to JWTs?
  • How do you keep the `sessions` table from growing unbounded, and how would you safely **rotate the password pepper** or **raise the Argon2 cost parameters** for existing users?