Event-driven Architecture Explained
Most applications on the internet work synchronously but this has been changing quickly in the last few years, especially because of IoT, self driving cars, etc. Synchronous applications receive requests to perform an action and the actor waits until everything is done, he/she waits for a response. However, there are situations when we don’t need to wait for a response but only send a request. It’s very useful when you just want to inform something or trigger a process and maybe check it later if everything went well.
Concept
Event-Driven Architectures (EDAs) are usually broker-centric, so there’s a producer that generates events/sends messages, a broker that receives the events and redirect to consumers, and a consumer that connects to the broker and waits for events.
Producer & Consumer
As explained in the first sentence above, a producer (aka publisher) is an application that sends messages to the broker and a consumer (aka listener) is an application that connects to the broker, manifests interest in type of messages, and leaves the connection open so the broker can push messages to them.
Message broker
A message broker (aka integration broker) is an application/software that translates a message from the formal messaging protocol of producers to the formal messaging protocol of consumers. There are a couple of famous brokers out there, like: Redis, RabbitMQ, Kafka, etc.
Message
As mentioned above, publishers send messages to a broker, and this message will be redirected and received by all the interested consumers. The message payload can be anything but they are frequently catalogued as events and commands. To clarify, events are used to communicate things to consumers and commands are used to ask consumers to do things.
Protocols
As we have HTTP and HTTPS, for example, used by REST APIs, there are also some protocols used by Async APIs. And these are some of them:
AMQP
Advanced Message Queuing Protocol (aka AMQP) is an open standard for passing business messages between applications or organizations. It connects systems, feeds business processes with the information they need and reliably transmits onward the instructions that achieve their goals. [1]
MQTT
MQTT is a machine-to-machine/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. [2]
Websocket
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. [3]
Conclusion
Now, we know a bit about event-driven architectures (EDAs) and that they promote the production, detection, consumption of, and reaction to events. An external information about them is that they are also extremely loosely coupled and well distributed.
We also know that there’s a big variety of protocols and to decide which one we should use is highly dependent on our specific use case and codebase.
References
1 — https://www.amqp.org/about/what
2 — http://mqtt.org/
