Careeroza
Why Event-Driven Communication
Request/Response vs Events
With Feign, order-service calls payment, inventory and notification services and waits for each. If one is down, the order fails. With events, order-service just announces "OrderPlaced #1001" to a message broker and returns. Every interested service reacts in its own time.
Synchronous (Feign) Event-driven (Kafka) order -> payment (wait) order --OrderPlaced--> [ topic: order-placed ] order -> inventory (wait) | | | order -> notification (wait) payment inventory notification one service down = order fails a consumer down = it catches up later
| Synchronous REST/Feign | Asynchronous events | |
|---|---|---|
| Coupling | Caller knows every callee | Producer does not know consumers |
| Availability | All must be up at the same time | Consumers can be down for a while |
| Latency for the user | Sum of all calls | Only the producer's work |
| Adding a new consumer | Change the caller | Just subscribe to the topic |
| Consistency | Immediate | Eventual (a few ms to seconds later) |
| Best for | Queries that need an answer now ("get price") | Facts that already happened ("order placed") |
Events in ShopEase
| Event | Producer | Consumers |
|---|---|---|
OrderPlaced | order-service | payment-service (charge), product-service (reserve stock), notification-service (SMS), analytics |
PaymentCompleted / PaymentFailed | payment-service | order-service (update status), notification-service |
ProductPriceChanged | product-service | search index, cart (price alert) |
UserRegistered | user-service | notification-service (welcome email), coupons |
Tip: Name events in the past tense (OrderPlaced, not PlaceOrder). An event is a fact; a command is a request that may be refused.