Entity Name

Description

Relationships

Customer

This is the most important user on the website. Every customer has a unique persistent entity that describes things such as the profile, history of bookings/interactions, payment preferences, and so on. When persisting, this entity has an unique customer ID, which can be used by other entities to refer to a specific customer.

Many other entities refer to a customer entity via the customer ID attribute (primary key).

Seller

Besides the customer, a seller is the next most important user on the platform. As mentioned, sellers can have varied characteristics. From a software perspective (of the limited requirements we have in the case study), the seller is effectively an API endpoint and a specific contract.

Many entities refer to a seller. In the database, these relationships take the form of a foreign key. But more interestingly, from the architecture perspective, we need to have a proxy for each seller, which also acts as an adaptor- interacting with the seller API on one side and the rest of the travel website platform on the other side. There will be more details on this in the following sections.

SKU

We need to have a unique ID for each item in our inventory. Although initially it looks as if the hotels and flights namespaces are distinct, a decision can be made to have a unique ID for each item across verticals.

A Stock-Keeping Unit (SKU) is a standard term for such an ID. Having this unique ID across all product lines will future proof the design for future use cases such as Vacation (Flights + Hotels).

This will be part of the primary key for the most of the data stores. This should not be re-usable , as there might be requirements to audit past transactions.

The SKUs form a hierarchical structure; specifically, some SKUs might have a parent SKU. For example, a hotel will have a SKU, and its parent SKU will be the ID of the city in which the hotel is located.

Date (check in/check out to/from hotel, for flights)

People want to search and book travel products on specific dates. The rates and availability will vary a lot according to the dates.

RFC 3339 is the standard for describing dates. It has multiple formats, and we need to choose something that is easy to model in persist entities and API exchanges. This leads to a certain Golang specific complication, and the solution needs a wrapper over the standard time. Time data type. Please see booking section for details.

Dates are not very interesting relationship-wise. They are mostly attributes of other entities.

Booking

A booking describes an intent to make a reservation for a flight or a hotel. Doing the actual reservation can be a complicated, time-consuming process, and a booking-persistent entity instance encapsulates all status about the booking.

Has references to the customer, SKU, and dates.

Reservation

During the course of making a booking, a reservation needs to be completed by the seller. The reservation entity encapsulates this information.

A booking entity has references (owns) multiple reservation instances. For example, a return flight booking might have flights from two different sellers, and thus includes two different reservations.

Wallet

As described in the requirements, we want personalized prices driven by a loyalty-rewards program. Essentially, whenever a booking is made, certain points get credited. The customer can utilize these points in making future bookings. The wallet balance is used for marked down in the search results page.

This can be modeled as an amount per customer. Besides the scalar value, we should also store individual transactions, essentially a ledger of the debits and credits to a wallet account. Though the later is not strictly mandated by the requirements, doing so would allow us to perform audits easily and handle related future requirements.