Loading...
GET
/Products/:filter&:page&:pageSize
Gets products
GET
/Cart/:userID
get Cart
POST
/CartItems
body: {productID}
Add item to cart
DELETE
/CartItems/
body: {productID}
Delete item from cart
POST
/Orders
body: {userID}
Create order for user
POST
/OrderItems
body: {listOfCartItems}
Create order items for user
Entities:
So essentially the rate limiter or the high level flow would be that the client makes a request to our API Gateway rate limiter load balancer and then that gets routed to our services so the product services and product service would primarily be used to get products filter products in the display on the client side for the user to browse our products and then the cart service would be a service where the user could for example they see a product they want they could add it to their cart and then keep track of sexually like what products they want to buy and so from there the. Music can also place to order and when the user places the order it would update our it would update our orders database with the order that it'll essentially everything in all products in the cart would be placed into would be using or order service to place an order.
And so this product or this order service would go through a third party API for payment such as stripe and then we would authorize this payment and for example a bit successful then it would place the order and then update our database that the order went through. And so because we're using a third party API for payment it'd be important for us to have you or item protein key and so for this we could generate a uuid key on the client side send it to our order service and then use that uuid to First plate try to place it in our orders DB to make sure that there's no collisions and once we successfully place it there we use item potency key to make a payment to stripe and then using that key strip would be able to do retry or anything else any other operations are the third party API would need within Idaho and once we get the response from stripe then we would go back to the orders DB and update the status of the order for example from pending to successful or failure.
Yep so to handle Scaling to scale the service offers to avoid any single point of failures we would have a replication. Of the for example the Gateway rate limiter the load balancer as well as each service and each database and Diving deeper into the databases. The It is separated into different databases first off and. Secondly the type of database I'd opt for in this scenario is because we're going for consistency I would opt for a sequel database like postgres where we would be able to leverage transactions to make sure that for example if there's any database conditions updating the same product or same inventory then we'd be able to use a transaction to make sure that. They would only be one right at a time or one read to keep everything consistent we could lock the row or depending on the isolation level we could set it at a specific isolation level to make sure that the data is accurate when updating the inventory or reading from the inventory. And for the replication I would go with a leader follower replication. And so all reads would be trafficked towards the. The read the replicas replicas and all the rights would be written to the master database to the leader. And The pending on the number of replicas we could set up a quorum. Or Just set a sync a synchronous replication. And so The inventory I think. Would be important? To have a synchronous just so. For example there's no double ordering when there's only one item left And the car. The cart could be a sink just because. Like it it's intended that one user has one card. Actually sorry the cart would be synchronous as well just cuz the cart service would we would grab the items from the cart to make an order and so the cart would need to be synchronous just in case like the user. Logs and somewhere else or like just logs and it hits the wrong database then all the sudden there would be inconsistency in what the user is expected. To have ordered versus what the user ordered. And so for that reason I would keep the card database synchronous as well products I think asynchronous is fine just because. The product is essentially just used to update our inventory and well that's usually like more. Back-end work like it's not client facing that's more so like administrator work or. Yeah internal work And Order service At the orders should be. Synchronous just cuz if a user makes an order it's important that they're able to see that order or keep it asynchronous but set it as read your own rights so whenever that specific user logs back and then they'd be able to see the specific see that the place to order already.