Loading...
GET /api/v1/items
POST /api/v1/pay
GET /api/v1/inventoryLevel to check the inventory level of all the items.
POST /api/v1/maintenance
POST /api/v1/refund
POST /api/v1/lowStockAlert for alerting when there are items low in stock
PUT /api/v1/restock to restock the items.
GET /api/v1/machineStatus
GET /api/v1/diagnostics
For Database we will be going with postgres.
Read Flow: Client -> CDN -> API Gateway -> Vending Service -> Kafka Queue -> Redis -> postgres
Write Flow: Client -> CDN -> API Gateway -> vending Service -> Payment Service -> Kafka Queue -> Redis -> Postgres
We have monitoring service to get the machineStatus and the diagnostics which might be required to know the status and metrics of the machine.
We also have inventory management service which is used to check for the inventory levels to set alerts on low stock and restocking of items.
We have payment service which is used to make the payments. It will also handle the refund mechanism as well. In case of payment failures we have more than one payment option. We will be providing the Cash/Coin options. We will giving the user the option to pay either through scaning the QR or through Cards. We will be using stripe as our main payment processor but in case it goes down we can use paypal as backup to have the payment service up and running.
We have Kafka queue for graceful degradation. In the sense if a service goes down it can pick from where it left because of kafka queue.
We are using redis for caching the data and to keep it fresh we have a cleanup service which cleans up the cache based on the ttl of the items. This cleanup service is also used to invalidate the cdn as well.
API Gateway is being used to route the traffic based on the api endpoint that is getting hit. This can also be used to authenticate the user and can be helpful in Preventing DDoS or Brute Force attack by implementing throttling.
When the network goes down we can store the transactions and data locally and then when the network is up we can sync the data to our main service.
We can have an endpoint to calculate the correct amount of change to return to the user.
Kafka Queue is being used to stream the data. It can be a very helpful component in achieving the graceful degradation. Let's say a service like vending service goes down which is one of the main services. We dont have to be tensed about losing progress and starting over making double orders since it will have the data in queue the vending service can pickup where it left off keeping the system from double ordering/booking. This also supports idempotency.
We have inventory Management service which is used to manage the inventory we can use it to get the inventory level like how many items are present and their individual counts. We can setup alerts when the item is very low in count so that we can restock it before hand which is also supported by the service.
Next we have the monitoring service to monitor the health and status of the vending machine we even have the capability to get diagnostics as to what happened. To keep this data safe we can encrypt the diagnostics so that no one can just tamper with the data in the machine.
For payments and refund we have payment service which handles all the payments we have options like cash, coins, card and QR. We will be mainly using stripe and as backup we will be using paypal if stripe ever goes down. The payment can be verified by using the stripe/paypal endpoint which returns if a payment is successful or not. Usually if something goes wrong in the middle of the payment if the money is debited from the user it will be credited back to them by default and this is handled by the payment processors themselves.
Vending service will also check if the item has been dispensed properly or not. If there is a failure in dispensing the item then the user will be refunded their amount that they paid for the item.
For any item that is getting concurrent purchases we will be having a time based block which will be there until the user either pays in which case he will get the item and if he fails to make the payment the block is removed and the other user is allowed to make the payment. If there are multiple items available we will be doing random blocking to allow as many users as possible to vend the item. If only one item is available then first come first served basis.
When the last purchase is being done for a only item we will be keeping the others in queue. If the purchase is successful then we will let them know that we are out of stock otherwise will let the next person to make the purchase.
When there is a powerloss or somekind of failure from the machine the transaction can continue where it left due to having kafka queue which will be having the data on where it was which the vending service can pickup and continue making the recovery more smooth.
During high payment spikes we can scale up our payment service accordingly and shard it so that the traffic is distributed along the shards. We will be randomly giving the users the items that are available because if we queue it normally it will more time. When the items are less and there is no possibility of random assignment then we will queue all of them and go one by one first come first serve basis.