Event-Driven Core, Request-Response Shell
There’s much uncertainty and doubt (and maybe even fear?) around event-driven architecture. One example is the belief that it’s irrelevant for REST APIs, as using HTTP verbs is quite clearly not event-driven. But behold - you don’t always have to go all-in to win.
Most modern applications provide an HTTP-based API on the server side, usually - more or less - following REST principles. The front end will instruct the backend to do something via a command, and get some response back.
An event-driven architecture, in contrast, is based on systems publishing things that have already happened. Facts. OrderSubmitted. PaymentReceived.
So let’s get that out of the way: For end-user interaction, being purely event-driven is not the right approach. After all, as a user, I want to tell the system to do something. Not give it a notification about what I have done.
The outside view of a typical such system is something like: A service that gets requests via HTTP, does some processing, and manages persistent state with the help of a database.
