This question is very loosely related to Axon Server / Framework since I'm learning it specifically while studying and trying to get into learning how to build microservices. Since it's difficult to learn about all the architectural patterns without actual hands-on experience (and difficult to get hands-on experience, to begin with without a large application to actually test/build with), I'm theorizing a lot here (my questions might just be plain stupid, sorry, I'm still learning).
I downloaded Axon Server and successfully built and ran the included giftcard demo in three separate microservices. It works great, I see the events and all that on the Axon Dashboard, but I can't help but think about the "what ifs" of if I really built a very large enterprise application.
Consider this :
I'm building a streaming platform like Twitch. There are basic, obvious services such as Customer service with its profile data, an order service (for subscriptions, donations), etc.
But there are other services such as the chat system. Hypothetically, I feel like event sourcing a chat system would be pretty beneficial because you would have timestamps built in for replaying the chat if viewers are watching a VOD. However, I also feel like I shouldn't be mixing events for a chat system with an event store that deals with transactions; the two are completely separate systems and just storing every event from every service in a single event store feels... Monolithic?
I'm still unclear what the best practices are. All the samples and examples from talks always show very simplistic systems with the typical Customer, Order, and Item aggregates and don't go into detail about how this simple application would grow to a large service like Twitch.
So my questions are,
Should you event source an entire application, or can you choose which ones to event source and not?
Does Axon Server support two different event stores, such as one for a chat system and one for other services? Would I just run two different instances of Axon Server in this case? Should an application ever have two different event stores, or do I dump every event into a single event store, regardless of whether something like a chat system sends far more events than anything else (would event sourcing a chat system even be a good idea, given the use case that I specified where viewers might want to "replay" the chat log?)?
The whole idea of a single event store being the single source of truth feels monolithic. Am I wrong in thinking this, and if I'm not, what are the ways to circumvent this if I had a really large application?
1) Should you event source an entire application, or can you choose which ones to event source and not?
You probably should not: If I would think of your applications as sub-domain models (bounded contexts) then I would be able to prioritize these subdomains as Core, Supporting and Generic. I would use eventsourcing pattern on Core (key differentiator for the business) and maybe Supporting sub-domains, but I would consider not using eventsourcing on Generic sub-domains. Generic sub-domains are usually something you outsource or buy, and they do not add much value to your business.
2) Does Axon Server support two different event stores, such as one for a chat system and one for other services? Would I just run two different instances of Axon Server in this case? ...
I have already mentioned Bounded Contexts pattern. Axon Server is enabling you to use this pattern. Axon Server Standard Edition has only one context (called default). In Axon Server Enterprise Edition it is possible to configure multiple Contexts, and then connect your applications to use them (in a role-based scenario). Each context is physically linked to its own event store/storage (one contexts = one store).
I would not mind keeping events in single Default contexts/eventstore for a while (using Axon Server CE). The thing with eventsourcing is that you are decoupling your data from the behavior, and it should be easy to migrate your eventstore to multiple eventstores in the future. I would focus on design and behavior of your applications now, and focus on migration latter. It is an evolutionary approach!
3) The whole idea of a single event store being the single source of truth feels monolithic. Am I wrong in thinking this, and if I'm not, what are the ways to circumvent this if I had a really large application?
I have probably answered this under 2). If you have loosely coupled applications and components (with location transparency included) you should not worry about your event-sourced data being in one eventstore that much. It can evolve to more event-stores in the future.