CODEWITHSUNDEEP
spring-bootevent-sourcinghystrixaxoncircuit-breaker
theNoobProgrammer
theNoobProgrammer

Reputation: 97

Axon framework and circuit breaker

I have been exploring axon framework and event sourcing for some days. I have a question now. Is there any possibility to implement circuit breaker pattern using hystrix in event-sourcing design pattern like axon? I have been going through the hystrix as well what I could understand from it, it's best to use when you have micro-services architecture using REST to communicate with each other, but in case of event-souring we don't have this scenario.

So my question is circuit breaker pattern is valid for the event-sourcing micro-services architecutre?

Upvotes: 2

Views: 371

Answers (1)

Nikola Yovchev
Nikola Yovchev

Reputation: 10226

First of all, a great and interesting question!

Short answer: Circuit Breaker and CQRS are two completely different patterns solving different problems, and as such can be used independently or together, depending on what problem you are trying to solve. Neither Axon nor event-sourcing as a pattern dictates that you have or not a micro-services based architecture.

Axon as an extremely flexible framework which is suited both for simple monolithic applications and also distributed microservices-based architectures.

Longer answer is below:

In Axon there are a couple of key concepts:

  • Command Handlers
  • Event Store + Aggregates
  • Event Handlers
  • Query Handlers

The idea is basically as following:

  1. You can dispatch a Command, which based on the specified Command Handler, will:
  2. Load an Aggregate from your Event Store, and passing some validation, would apply the event,
  3. Then all your Event Handlers will fire.
  4. Query Handlers are the other side of the story, which basically means some of your components wants to get some data, and each request for such data is dispatched to one or many Query Handlers.

For a more detailed overview of these concepts, take a look here.

On the other hand, Circuit Breaking pattern is a pattern which allows resilience within your application and doesn't allow it go get overwhelmed with requests.

There are couple of conceivable scenarios where you can apply Circuit Breaking together within Axon:

  1. Too many requests for data can overwhelm your Query Handlers (think DDoS attempts or sudden spikes of traffic) and you might not have the ability to scale the underlying infrastructure. However, if you have some defaults that you can serve to these as an alternative Query Handler, then you can serve those.

An example situation for using Circuit Breaker in Query Handling can be a recommendations engine where instead of serving personalized products, when your Circuit Breaker opens, you'd serve some default products.

  1. Similarly, if you have too many commands, your underlying infrastructure also might not be able to handle that. Each command generally requires loading the Aggregate from the event store, applying some validation, and maybe even further firing some events to the Event Handlers. If you have too many commands coming in, your underlying event store and event handlers might crash or grind to a halt, and this is another place where you can apply the Circuit Breaker pattern.

An example situation for using Circuit Breaker in CQRS Command Handling can be a simple system where you allow users to create their account, change their name, and delete their account. If any set of particular users starts changing their name once in a while, it's completely okay. However, if suddenly, a user decides to start changing his username 10000 times per second, that might be too much for your underlying databases. That's why if you detect such behavior, you can apply circuit breaker pattern for this specific user and allow them to 'cool-off' so that your normal traffic goes undisturbed.

That only are some simple scenarios where you can Use CQRS and Circuit Breaker pattern together, but the possibilities are endless.

One final note is to take a look at resilience4j as an alternative to Hystrix as in the recent years its userbase and adoption has rapidly grown and it's significantly more lightweight than Hystrix. Additionally, as you can see in Hystrix's github page:

Hystrix is no longer in active development, and is currently in maintenance mode.

and

For the cases where something like Hystrix makes sense, we intend to continue using Hystrix for existing applications, and to leverage open and active projects like resilience4j for new internal projects. We are beginning to recommend others do the same

Upvotes: 4

Related Questions