Event-driven architecture
Event-driven architecture explained: events versus commands, publishers and subscribers through a broker, choreography and orchestration, the outbox pattern, idempotent consumers, eventual consistency, event sourcing, and the trade-offs to weigh before adopting it.
CodexBash, , 5 min read
In a typical system, when an order is placed, the order service calls the payment service, then the inventory service, then the email service, waiting for each. Every new feature adds another call, and if any service is down the order fails. Event-driven architecture turns this around: the order service simply announces "an order was placed", and every service that cares reacts on its own. The order service no longer knows or waits for them. This article explains the idea, the patterns that make it reliable, and the costs that come with it.
Sign in to read the rest
The whole 5 minute article is free with an account, along with every problem, lesson and tutorial. No card.