ADR 1 – Asynchronous Purchase service
STATUS: Accepted
CONTEXT: Purchaser tracker service the initial goal was to handle the customers interactions, so that the transaction is communicated to the vendor. This interaction can he handled as a REST API or asynchronous pub-sub model. More the Point-Of-Sale (Smart Fridges and Kiosk) we have the traffic can go up significantly.
We have seen good amount of interaction of Purchase tracker service to be able to handle the payments and deal with integrations with different payment providers.
DECISION: We will use asynchronous pub/sub messaging between these two systems i.e. Point-Of-S ale to Purchaser tracking system. The Point-Of-Sale systems has no use of the response status back from the Purchase tracker system. These events can be published in batches on regular intervals.
Based on the above decision, Purchase-tracker service will be able to process events at its own consumption rate and any failure in Purchase-tracker service will not result in impacting all the Point-Of-Sale systems.
CONSEQUENCES: If we go with multi-region deployment, we have to handle the duplicate sale event getting processed across regions. There should be a unique way of generating the event id either in the Point-Of-Sale systems or the unique event id’s can be generated by a service.
COMPLIANCE The events has to be end-to-end encrypted on the wire using https. PCI compliance is required by credit card companies to make online transactions secure and protect them against identity theft. Any merchant who wants to process, store, or transmit credit card data is required to be PCI compliant, according to the PCI Compliance Security Standard Council.