Event-Driven VS Request-Driven Architecture, User Registration Example (Pros & Cons)
In this post, I am running you through two different approaches for implementing a user registration process to share the trade-offs, the differences and the advantages and disadvantages between the two different architectural patterns.
Note – This post is the written version of my YouTube Post of the same name, which I have linked to at the bottom
So we have two different solutions, both have two services, one displaying the UI and the other service handling the processing of the registration request.
The event-driven solution communicates by publishing and consuming events via a messaging platform which has two event queues, or topics, depending on your terminology, I will use the term topics in this post as I have been using Apache Kafka for the last couple of years,
And the request-driven solution communicates via a synchronous web service, like a restful API.
For the Event-driven solution, when the user submits the registration request, the registration client will publish an event to the registration queue topic (the request topic in the diagram), which will be consumed and processed by the Registration processing service. Once the request has been processed, the result would be published to the completed event topic, which the registration front end would be listening for and would present the outcome back to the user.
The request-driven solution would make a single request to the processing service, and the client would wait until the processing service responds with the result.
Benefits of loose coupling
But now what happens if the processing service encounters issues, or is not available.
In the Event-driven approach, the client would still be able to publish the registration request event because, in event-driven solutions, the publishers are naturally decoupled from the events’ consumers and would not be aware of any problems. And because of decoupling, there is no time dependence, and consumers can consume events at their leisure.
When the system becomes healthy again, it will process the requests that have not been processed before.
It is important to note that if a solution is not designed correctly or the feedback to the request’s initiator, the user trying to register in this example, is not designed correctly. This could lead to unintended outcomes and inadequate user experience.
Why?
Because the initiator of the request, the user, may no longer be using the application or have the session open. (It could be minutes or even hours before the request processing is resumed).
So rather than keeping the user waiting for an infinite period of time, you may want to inform the user the system will notify them of the outcome via email.
For the request-driven solution, if the processing service is unavailable or encounters issues, the client will be quickly notified, or the request would time-out. Now, of course, you may want to retry the request multiple times automatically.
However, if the service is not responding, you would need to inform the user that they cannot register.
In some cases for request-driven solutions, you could degrade functionality gracefully, but in this example, you properly won’t have an alternative service for registering users. So inform the user to try again later.
Now let’s wrap this up.
So once when the processing service is healthy and is processing requests, the event-driven solution would notify the user of the result.
Now you maybe think, will Daniel, most registration processes email the users once registration has completed. Which is true, but in this example, I’m making a point of pointing it out to you, because in other use cases, aside from user registration, you need to be aware that consumers can process requests independently of time and this has to be catered for.
And it is good practice to have notifications triggered by events.
Whereas in request-driven solutions, what happens if you can’t send the email or have fired off the email but can’t complete the activity. What do you do? (I’m not going to answer that question)
And regarding the request-driven solution, users can now navigate and re-submit their registration requests when the system becomes healthy again. IF they have not gone somewhere else, and still want to use your service.
Summary
Architecture is about understanding the trade-offs to design and develop the correct solutions that deliver what the business requires when the company needs it.
The Pros of event-driven vs request-driven
- Increase Resiliency and recoverability
- (Time) Independent processing – Consumers can process events when they can.
- Publishers, the clients, are decoupled from the consumers of events (requests) and can still publish events (requests) even if the consumers are unavailable or in a faulted state.
The Pros of request-driven vs event-driven
- Fail fast – Now even though in this example it may not be seen as a benefit, for some solutions, not having feedback quickly or having events processed at a later point in time may have negative consequences.
- Less infrastructure – nowadays creating web services exposing REST APIs is simple (don’t mistake simple for easy) and does not require extra services and infrastructure to support messaging platform.
- Simpler to develop, maintain and less complicated – event-driven systems are complex, they come with additional design consideration to cater to the problem. Take the event-driven solution it had far more components than the request-driven solution.
YouTube Version
Thank you for reading to the bottom, please go check out the YouTube version