aioff.
中文
Product design
PRODUCT DESIGN·5 min

Airbnb: know whether a booking request is sent or a stay is confirmed

Airbnb helps travelers find and book accommodation. Some stays can be confirmed immediately, while others need a host response. Knowing which path you are on helps you tell when your plans are settled.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

01
CODE EXERCISE

Encapsulate booking-request state transitions

Suppose you are building an accommodation app’s booking-request page. Its buttons and status card need one shared module so that a withdrawn request cannot accidentally become confirmed. Implement a ReservationRequest module.

  1. Initial state and events: Each request starts as pending, waiting for the host. apply(event) accepts accept (host accepts), decline (host refuses), withdraw (guest withdraws), or expire (deadline reached). Inputs are guaranteed to be one of these events. The caller decides whether the deadline has passed.
  2. State rules: From pending, those events lead respectively to confirmed, declined, withdrawn or expired. These four states are final and reject every later event. Provide a read-only state query; modifying its returned value must not alter the module’s internal state.
  3. Results: Success returns {ok:true,state}, with the actual new state. An event received in a final state returns {ok:false,state,reason:"already-final"} and keeps that state unchanged.
  4. Check and deliver: Request A receives withdraw and becomes withdrawn; a later accept is rejected and leaves it withdrawn. A separate request B receives accept and becomes confirmed; another accept is rejected. A third new request receiving expire becomes expired. Submit the module, an interface explanation and results of these local calls. Do not implement timers, payments or a page.
Explore the reasoning

  1. Keep state inside the module and send changes through one entry point. Expose only the information callers need.

  2. Consider allowed transitions from pending separately from rejections in final states. Check that the result describes both the action’s outcome and the actual state.

  3. Trace A and B to check that final requests cannot reopen and instances do not affect one another. Then check that external changes cannot bypass the rules.