Implement auth and profile APIs

Quick Overview

This question evaluates backend API design competencies such as authentication and bearer-token access control, user profile data modeling, input validation, error handling, and state management for an in-memory service within the System Design category.

Implement auth and profile APIs

Company: Speak

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Implement an in-memory HTTP API for user authentication and profile management. Support: register (email + password), authenticate (login), retrieve and update a user profile, and delete a user account. Model the data structures you would use, define request/response schemas, and outline basic validation and error handling. Assume password hashing is a mocked placeholder and no database is needed; focus on an MVP. Provide example endpoints and discuss trade-offs and how you’d extend it later (sessions/tokens, password resets, audit logs).

Overview: This question evaluates backend API design competencies such as authentication and bearer-token access control, user profile data modeling, input validation, error handling, and state management for an in-memory service within the System Design category.

|Home/System Design/Speak
Speak logo
Speak
Sep 6, 2025
mediumSoftware EngineerOnsiteSystem Design
10
0

Design an In-Memory HTTP API for Auth and Profile Management

Context

Design a minimal, single-node, in-memory HTTP API that supports user registration, authentication, profile retrieval/update, and account deletion. Assume no external database; persistence is lost on restart. Password hashing can be mocked.

Requirements

  • Implement the following endpoints:
    1. Register a new user (email + password)
    2. Authenticate (login)
    3. Retrieve current user profile
    4. Update current user profile
    5. Delete current user account
  • Provide data models and request/response JSON schemas
  • Include basic validation and error handling conventions
  • Discuss trade-offs and possible extensions (sessions/tokens, password resets, audit logs)

Assumptions

  • Single-process, single-instance server (no clustering)
  • Password hashing is a placeholder function; do not implement real crypto
  • Access control for profile endpoints uses a bearer token returned by login
  • Focus on an MVP suitable for an onsite system design interview

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...