A POS System resembling in many ways the famous Amazon Go project. This project allows a customer to select products and pay through an app with minimal checkout requirements. Products contain a qr-code allowing a per item real time price adjustments depending on variables like expiration date and time, Each product can have signals and tags attached allowing for promotional actions etc..enabling the possibilities for customer interactions etc.. This system also has the following components: Product purchase mechanism, delivery mechanisms, instore and online sales, complete registration of product life cycle, employee management, electronic device interactions, ePaper displays etc..
Key features are:
Due to the nature there were some requirements such as low costs of code maintenance, deployment, etc.. There were challenges that needed to be overcome.
1. First is how are you going to integrate multiple systems that have fundamentally different natures. for example, the rest api was made in laravel. and rest is by nature bi-directional (as opposed to an event system that is unidirectional) Second laravel is built upon php which is by default a session based language. So connecting a session based rest api connecting to for example an aws activemq instance is rather challenging because connections are not persistent between sessions for example. Other issues in a distributed system is of course latency of the content delivery due to caches. To this end I created a special producers\consumers to bridge the api and the message queue
2.Because we were moving from an api first system to a more complex event driven architecture, there is a need to seamlessly communicate between the various components. One of the observations is that most events are generated within the api. This means that over 90% of the requests flows involve the api generating events, that in turn collect data from the various processes connected to the message queue and then forward this information to external clients. The complexity of development has now significantly been reduced, using a new message format that allows us to address these flows in a rather simple fashion. This format allows us to build feature flows without having any knowledge about the underlying transport.
Developer Deployment: This project is handled within docker for both deployment and local development. This means new developers are set up in hours and are easily set up focusing them on their respective areas for maintenance. This project will be rolled out on per customer per country base in the beginning and ci\cd will be phased.
Architectural decisions The reasons for selecting this architecture over a true kafka based solution were several. 1. First the project was developed in-house, meaning you need local talent to build and maintain this project. Where we are based, there are more node developers available then pure java developers, and there is also a cost aspect related to that. 2.The strong need to have a good balance between api\rest development and event producers \ consumers. 3. This project had some moving goal posts and targets. The architecture and apis needed to be flexible enough to satisfy the changing requirements. (within reason) 4. Having previous experiences in the fields of POS development, working with companies like Albert Heyn, Walmart and other large scale companies in related areas of logistics and software development, I was able to inject these experiences to further improve and guide this project.
All being said, The most important reason that carried this project was a thorough understanding of the client's wishes and the goals they and I wished to achieve. Combined with my own experiences within the retail and business sector, this was the main reason for the project's success.