From Service | To Service | Techno |
---|---|---|
Checkout | gRPC (send mail) | |
Checkout | Payment | gRPC (charge card) |
Checkout | Shipping | gRPC (ship order, Get shipping quote) |
Checkout | ProductCatalog | gRPC (GetProduct) |
Checkout | Cart | gRPC (get/empty usercart) |
Checkout | Currency | gRPC |
Recommendation | ProductCatalog | gRPC (ListProducts) |
Cart | CACHE REDIS | |
Frontend | Ad | gRPC |
Frontend | Checkout | gRPC |
Frontend | Shipping | gRPC |
Frontend | Currency | gRPC |
Frontend | ProductCatalog | gRPC |
Frontend | Recommendation | gRPC |
Frontend | Cart | gRPC |
Most communications between microservices are decoupled using the EventBus and the "pub/sub" pattern. However, the communications between the custom aggregators and the internal microservices is currently implemented with gRPC as said here.
| Basket | Catalog | | Basket | Order | | Basket | Identity | | Order | Identity | | Marketing | Location | | Marketing | Identity |
Extracted from here
-> All services communicate using REST
-> Shipping send orders to a queue
for sending them out
| Cart | | Catalogue | | User | |Cart | | User | |Order | | Order | |Payment | | Order | |Shippinh |
| Inventory | | Redis | | User | | MySQL / Rest | | Product | | MySQL/ Rest | | Store | | Mongo/ Rest | | Order | | MySQL | | Inventory | | Redis / Rest | | Product | Inventory | |
=> RPC on eventbus + bidirectionnal Rest
From | To | because |
---|---|---|
Checkout | Catalog | remove product in catalog |
Checkout | Payment | make payment |
Payment | Notification | payment completed |
Payment | payment completed | |
Checkout | Order | Checkout, order status ; compensate order status |
Everything is done via Saga pattern (a service registry that acts as an orchestrator here (not a choregraphy).)