Designing a Point Of Sale system — Part 3

In the previous article, i have explained how we can design simple POS with minimal features. I also mentioned that there are few trade-offs with that design.

Let’s see what the trade-offs are:

1. Tight coupling between items lookup, pricing and payment
2. The system will not be scalable if POS is used by many outlets
3. If many channels (such as store, app, vendor etc) are being used, then we end up with latency and data reconciliation issues.

So how can we address these concerns and design a highly scalable POC ?

Let’s talk about this design:

1. as I said, one of the trade-offs is tight coupling between item availability, pricing and payment. First we should decouple them.
2. For this, let’s create an item availability datastore. since item availability should be shown in milliseconds, we need to have a dedicated datastore (preferably a NoSql).
3. Who is going to populate the data? The data will be replicated from Inventory DB through an event. whenever there is a new item added into the inventory, an even will be fired which will be subscribed by item lookup event listener and it will persist in Nosql DB
4. Item lookup service will get the data from Nosql and it will be shown in UI or any other channel
5. when a user completes payment, depending on the payment status (success or failure), an event will be fired with the status and the inventory will update accordingly.
6. Payment history, through CRM, will be updated once the payment status is updated through an event.
7. CRM system will be used so that customers can see the purchase history and also set the customer preferences.

Design considerations:

1. Why NoSql? — Since item lookup (or availability) is a highly read intensive operation and the response should be returned in milliseconds, It’s better to read the data through a Nosql. The read, through NoSql will be much faster than a typical RDBMS. If latency is not a concern, then we can use RDBMS (such as Oracle or Sql server).
2. Event Bus — event sourcing can be used to process the events at scale. This ensures the requests can be processed in sequence at scale.

If you have any questions or concerns with the content, then feel free to DM or reach out to me through my email id : kiran.mvv@gmail.com or LinkedIn — https://www.linkedin.com/in/kiran-mushnuri-7b09a73b/