Hi @Robert , this is one way of solving a scaling problem. It only works for a very specific subset of scaling problems, caused by the need to pick a stream of related events from a coarse, static topic address scheme that does not enable fine grained topic filtering and where the operational overhead of running your message broker is so high you have no alternative but to use it as your sole persistence layer. Event sourcing is great, but not when the persistence layer forces you to adopt one particular application style like this.
Solace has many use cases handling many more that millions of messages per hour - try 100B a day.
Some other approaches:
Sharding with topics. Have topic taxonomy salesOrder/{verb}/{id}. Now you can filter for order “1” and allocate that to a particular application/application instance. You can filter on just about any criteria, actually. What’s great is that if, later on, you need to further decompose your microservices so that you have separate create and update services, you can do that two. No need to change your topic. No need to change the number of partitions as your scale. No topic or partition rebalancing. Use polyglot persistence. Your example assumes each instance of the service has to own everything that happens to a particular order id, because the microservice’s persistence is local to that instance of the microservice. People tend to assume this is what ployglot persistence means, but it doesn’t: it means “use the persistence layer most suited to that particular microservice.” So, don’t throw away caches and traditional DBs, amongst other options. This is especially true of situations where updates are not easy to separate in to isolated entities like this (where in this case the entity is the order number). Client based routing/filtering. Instead of basing your unit of scaling on the business object (sales order) in this case, why not base it on the real unit of work here - the customer? That way your event stream has all the events relating to the customer - a much more powerful concept that makes building omni-channel interfaces and single customer views much simpler, and makes dynamic allocation of applications instances much simpler. There are many, many different ways of scaling. At Solace, we enable you to pick whichever suits your use case, rather than forcing you to architect everything to overcome limitations in your messaging layer.