Just 20 years ago, most of the business was offline and web development was just starting to gain traction. But gradually everything develops, the whole business is trying to go online. And along with it, web development is actively developing, there are more and more services. Web development is an integral part of any modern business.
To keep our business running fast, we need to consider all the third-party services on which our business depends. First, let's take a look at the standard architecture we're used to.
Standard Client-Server architecture
With a standard synchronous architecture, most changes have a large number of dependencies, sometimes on slow and unpredictable systems. This slows down interactions and increases the error rate. Maintainability is troublesome, as there is usually a high amount of possible side effects to consider.
👍 Advantages:
- Simple to understand
- Easier to debug and test
- Better data consistency
👎 Disadvantages:
- High rate of client-visible errors
- Slow
- One thing fails, everything fails - does not work well for complex business processes
Event-Driven architecture
In an event-driven architecture, when a service performs some piece of work that other services might be interested in, that service produces an event — a record of the completed action. Other services consume those events so that they can perform any of their tasks needed as a result of the event.
By decoupling the core change from the side effects performance is greatly increased and error rates go down.
Secondary concerns can be handled independently, this allows easier maintenance, and even involving different teams and/or technologies that are best suited for the respective tasks.
👍 Advantages:
- Responsive
- Resilient
- Scales as a whole as well as only where needed
- Development can be distributed between multiple teams
👎 Disadvantages:
- Extra work needed to keep data consistency
- Higher learning curve
Summary
Event-driven architecture has been gaining momentum in popularity lately, and there are reasons for this: services grow and develop, become larger and acquire new dependencies. Decoupling of responsibility can be a solution in this case and improve performance, but you shouldn't abuse the architecture without a detailed understanding of all its pros and cons. For small and simple projects, a standard synchronous architecture may be a much better solution.
To read more, follow these links:
- What is Event-Driven microservice architecture?
- The Challenges of Building a Reliable Real-Time Event-Driven Ecosystem
Interesting in reading more about APIs? Follow this link to find more articles 😉
Top comments (0)