Appointment Service Design for eCommerce Applications

There are appointments in many different eCommerce scenarios. Whether it’s in the form of a movie ticket, an airplane ticket, or an oil change, each appointment scenario requires specific business rules and technical decisions to properly design its system. Assuming that you’ve chosen a service to serve as the appointment master, this design will outline the necessary steps to properly expose that service in your eCommerce application. In this first half of a two part series, I’ll introduce the considerations and challenges developing a service like this poses.

Different Kinds of Appointments

When determining the business and technical decisions needed for your appointment service, it’s imperative to understand what kind of appointment you’re incorporating in your application. There are two distinct types of appointments:

1. Appointment as Purchase

2. Appointment with Purchase

Appointments as the purchase encompass purchases like an airplane ticket or a haircut appointment. The distinguishing feature of these appointments is the limitations of the seat or appointment. You simply cannot fulfill two customers who buy the same ticket of this nature. Contrast these scenarios to those in which the appointment comes with the purchase of something. For example, consider what happens when purchasing an oil change at a car shop. The number of bays at the auto shop, number of mechanics working, and other customers at the time of the appointment all have an impact on the appointment experience. Given the major differences between these two kinds of appointments, it’s clear they’ll require different designs.

Race Condition

A race condition is the behavior of software when the output is dependent on the sequence of other uncontrollable events. In the scope of appointments, let’s consider an application for purchasing concert tickets. There is one more available seat at the venue before this concert is sold out, but two customers enter the checkout flow at the same time with this final seat selected. If the application is not designed for such a scenario, it’s possible the concert will be oversold. If it is designed for this scenario, this race condition will be handled before both orders are complete.

In all kinds of appointments, the race condition is extremely important to consider in the early stages of the design. It’s critical to understand how you plan on presenting the appointment to the customer and what sort of race condition this experience introduces. Two people purchasing concert tickets with the same seat should result in an error in the checkout process to prevent overselling, which poses some critical questions for your application design:

• How do you prevent this scenario from happening?

• At what point during the checkout process will your application be checking for this scenario?

• How often do you anticipate this race condition happening?

All of these questions help drive both the user experience and technical design of the service.

Appointment as Purchase

Since the purchase in this scenario is the appointment itself, a company selling a single appointment to multiple customers is likely going to result in a very bad customer experience for at least one of those customers. Given that, the first goal should be to never allow two orders to succeed for the same appointment. This can be achieved by setting up the service with a queue that reserves the appointments in the order it received it. An alternative solution could be administering a hold on the specific seat as soon as the customer selects it during the checkout process. Details about these solutions will be covered in the second part of the series.

When the risk of two customers successfully reserving the same appointment is eliminated, the focus should then shift to recognizing when a scenario like this is introduced, the frequency of the scenario, and the subsequent customer experience that follows. Once the race condition locations are determined, adding checks to the appointment service at these points to determine the availability of that selected appointment is a good way to prevent customers from continuing the checkout process. While this helps recognize race conditions sooner, it’s important to consider the frequency of the race condition at each location you’re considering adding these checks and the performance impact of these calls.

If 1 in every 10 attempted orders is rejected due to a race condition, prioritizing the customer experience over performance is likely a better choice than if it were only 1 in 100 orders. Including more checks to the appointment service throughout the customer experience could decrease performance, but could also increase the customer experience significantly. Understanding exactly how customers use your application is crucial in weighing these trade-offs. Each appointment scenario is unique, but calculating the race condition frequency for your customers is important in choosing how to handle this situation from a user experience perspective.

Appointment with Purchase

While the race condition drives the design for appointments as purchase scenarios, it is just one factor for the design of appointments with purchases. Since the purchase itself isn’t the appointment, there are more factors that go into defining the race condition in the first place. Take an oil change appointment at 1:00PM as an example. How many appointments does an auto shop allow for this time slot? The inventory of the oil purchased, the number of mechanics, and the day of the week are just a couple factors that go into defining the limits for the number of appointments at each time. Furthermore, it requires looking at the type of purchase that took place. If you allow for appointments for different purchases, say an oil change versus a transmission replacement, your appointment service needs to account for the effect each kind of purchase has on the overall operation on the appointments itself.

Once these factors have been properly assessed and defined, it’s then possible to understand the limitations that need to be put in place in the business logic for your appointment service. While this business logic can be complex, the race condition limits are less important for appointments in this scenario since the appointment itself was not the purchased item. Of course, you should still design your application to avoid the race conditions the best you can, but the consequences of exceeding your defined limitations are much lower.

Key Considerations

Beyond the kind of appointment you’re developing this service for, it’s important to understand a couple more factors in the design phase.

1. What appointment operations will your application support?

   • Beyond the reservation of an appointment, will your service support editing or cancelling? For hotels or airlines, there’s often a penalty in a cancellation or modification to an existing appointment. Incorporating other operations on an appointment introduces additional business logic for which the design will have to account.

2. How do you identify a race condition and how do you present it?

   • It’s critical to understand when you’re in a race condition. It’s equally important to determine the best way to present this to the customer. Understanding how customers use your application and the frequency of these race conditions are critical in determining how you handle this situation.

3. What is the order velocity?

   • How quickly are customers booking appointments in your application? The higher the velocity, the more robust your race condition coverage should be.

In part 2, I will cover the technical solutions to address some of these key points in moving forward with your new appointment service.