I’ve been thinking about a problem that I’ve solved before. I’ve solved it a million ways but I’ve never really thought about which approach is best. I’ve decided to request some input on the subject. I’d appreciate your thoughts.
The Scenario
You’re a business with multiple locations and a single website. You want be able to allow customers to log into your site, and order something from one of your locations, but you want to give the customer immediate confirmation that their order was received by the store location — not just that the website received the order.
That means you only want to let the user know they can rest at ease knowing their order has been received by the people directly responsible for holding/delivering/shipping your product.
Application
The scenario above could describe any number of business. This could be a retail business. You may want to make sure that the store knows to hold a piece of inventory for a customer who is on their way to get it (think Best Buy’s “in store pickup”). It could also be something much more loosely connected by even legal boundaries like OpenTable does when it allows you to make reservations for a number of restaurants for open times.
Solution Approaches
There are obviously a number of ways to solve this problem and the application may very well dictate the solution you pick. There are three main approaches, and within those approaches, there are several technical ways to solve the problem.
Centralized Approach
In the OpenTable application, you could, for instance, require all reservations be made through OpenTable’s website. In that case, it means that even if someone called a restaurant, they would need to use the website.
The downside to this is what happens when the internet connection between the restaurant and OpenTable.com is interrupted. People calling the restaurant wouldn’t be able to make reservations but people on the web would. Alternatively, the restaurant and the web would be out of sync and more reservations would be made than are available.
Distributed/Brokered Approach
This approach says that each location is responsible for it’s own allocation of inventory/product/time slots. The website simply acts as a broker and sends orders to the location. This means that the website must collect the intended details and get them to the store location. There are two problems with this approach.
First, the communication from the centralized approach is still problematic. In the reservation scenario, you can’t simply store the request at the server and send it when communications return. The reservation may not be available. Ditto that with the inventory issue. If that elusive Tickle-me Elmo doll is in stock, you want the customer to be able to buy it and secure the inventory for in-store pick-up.
The second issue to determine is whether you want a push mechanism from the website to the remote location, or if you want a pull mechanism that polls for details on a regular basis. Because the inventories are disbursed, there is also some synchronization that needs to occur. You need to make sure that if you say there is an item in inventory, that there is. If it’s purchased at the store, you need the website to reflect that. If it’s purchased/reserved on the website, you need the item/reservation to be updated at the location.
Delegated Approach
There is another approach which is a bit less risky. This approach delegates a certain amount of guaranteed inventory from a remote store location to the web. This allows you to treat the web as it’s own store, handle it’s own inventory, and simply sync with the remote locations as you can. This is a problem for retail locations that do this, however, because you have to maintain two different inventory statuses — in inventory, but allocated for in-store pickup. It’s not as big of a deal for things like restaurant reservations because they aren’t “real” entities that require inventory shuffling. There are definitely benefits to this approach, but it wouldn’t work for something like, for instance, grocery delivery.
My Solution
The solution I’m inclined toward is to use the distributed approach. When someone submits a request, it will be queued up, and an attempt will be made to submit it to the remote location, when the remote location receives the order, it will return a confirmation which will then be returned asynchronously to the user (either through polled HTTP requests or other means — Twilio, for instance). If the location cannot be reached, it will simply return an error to the user with instructions on how to contact the store directly. This is a fairly common approach.
Questions to the Community
So now that I’ve laid out my thinking, I’d like to ask some questions to you all. If you feel so inclined, please feel free to post your responses in the comments. Thanks very much in advance.
- Am I missing any approaches above? Is there another approach I haven’t considered?
- Are there any downsides that I’m missing?
I’m looking forward to hearing from you.
