Design and evolve a reservation system

Read the full interview experience this question came from →

Quick Overview

Design and evolve a reservation system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design and evolve a reservation system

Company: Nordstrom

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design an online reservation system that supports creating, modifying, and canceling reservations while preventing double-booking. Specify APIs, data model, consistency guarantees, idempotency, concurrency control, and handling of capacity limits, waitlists, and expiration/TTL. Discuss trade-offs between alternative approaches (e.g., optimistic vs. pessimistic locking; relational vs. NoSQL; centralized vs. sharded inventory). Explain how you would scale the design as traffic grows (partitioning, caching, queues, rate limiting, backpressure, monitoring, failure recovery). Identify key security and privacy concerns and mitigations. Which deployment strategy (blue/green, canary, rolling) would you choose and why? When designing features or services in general, what principles and risks do you prioritize first?

Overview: Design and evolve a reservation system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Read the full Nordstrom Software Engineer interview experience this question came from

|Home/System Design/Nordstrom
Nordstrom logo
Nordstrom
Jul 17, 2025
hardSoftware EngineerOnsiteSystem Design
10
0

Design and evolve a reservation system

System Design: Online Reservation System

You are designing a backend platform to book time-based slots for services or events (e.g., appointments, classes, tables). Each resource offers time slots with a fixed capacity. The system must prevent double-booking under high concurrency and support lifecycle operations.

Assume a single region to start, with the need to scale reads (availability lookups) more than writes (bookings). Payments are out of scope; focus on reservation integrity.

Requirements

  1. Core capabilities
    • Create, modify, and cancel reservations.
    • Prevent double-booking and overselling capacity.
  2. APIs
    • Specify external-facing endpoints and request/response behaviors.
    • Define idempotency strategy for write APIs.
  3. Data model
    • Entities, relationships, and key indexes/constraints.
  4. Consistency and concurrency
    • Consistency guarantees for reads/writes.
    • Concurrency control approach to avoid double-booking.
  5. Capacity, waitlists, and expiration
    • Capacity checks, holds, waitlist mechanics, and TTL/expiration handling.
  6. Trade-offs
    • Optimistic vs. pessimistic locking.
    • Relational vs. NoSQL stores.
    • Centralized vs. sharded inventory.
  7. Scaling and reliability
    • Partitioning, caching, queues, rate limiting, backpressure.
    • Monitoring, alerting, and failure recovery patterns.
  8. Security and privacy
    • Key risks and mitigations.
  9. Deployment
    • Choose between blue/green, canary, and rolling; justify your choice.
  10. Product engineering principles
  • What principles and risks do you prioritize when designing features/services?

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Nordstrom•More Software Engineer•Nordstrom Software Engineer•Nordstrom System Design•Software Engineer System Design