Serverless transaction processing on AWS
One of my recent encounters in integrating point of sale systems with reward solutions required processing transaction that were captured by the point of sale systems.
Ideally the flow starts with a Customer that would purchase something from an outlet, that would then get captured within the point of sale system. This information of the successful transaction is then posted to the system that handles the rewards for that retail merchant. In most cases the these solutions would have endpoint that would capture single or bulk transactions that would then be processed in realtime or asynchronously.
Rewards solution would then perform its magic on top of these transactions based on the mechanics that has been configured. The Reward solution, would have a customer facing interface that is either a mobile application or a web app that would present this information.
When managing these rewards solutions, one of the most tricky areas is handling the way how transactions get posted to the system so it could process them accordingly. Having a dedicated endpoint ( ie. REST ) is a simple solution that works in most cases. But over-time managing the evolution of this endpoint becomes quite a challenge as once its integrated, its very unlikely that a Point of Sale vendor would go trough an upgrade easily or at least convincing them to do so is going to be a bigger challenge.
To counter this problem, one solution I found quite appealing was to offload the responsibilities from the point of sale for transaction processing. This simply means that, as far as the point of sale system is concern what it does is in most cases push out all the information that is necessary or available to a designated messaging queue, in this case AWS SQS.
The advantage with this is, we can have multiple transaction queues for each merchant that we work with. If your application is a multi-tenant solution you would understand that POS integration are challenging and they differ from one to another. This way we will be posting the transactions to a queue then a Lambda function that would handle the data transformation and sanitisation.
Ideally following the Lambda function depending on your use case you could either fan out or pass the message along to SNS or another SQS endpoint.
One key pointer is that, its mandatory that we ensure transaction idempotent. Since SQS guarantees at least once delivery there is a chance or multiple deliveries.
Another alternative approach is to replace SQS with an SNS endpoint that will invoke the Lambda function on each hit. With the way how Lambda works, this is quite a cost effective method since we don’t have to poll an SQS queue for the initial data transformation. This allows us to fan out once the data transformation is done, and we can handle side effects from the transaction processing accordingly.
