Brian Richardson's Blog

Modern Design Techniques – Event Sourcing

June 20th, 2022

I’ve spent the last few months studying Alexey Zimarev’s excellent book, Hands-On Domain Driven Design with ASP.NET Core (2017). While 5 years old now, it was clearly cutting edge at the time, since the Event Sourced system he demonstrates is now becoming more popular. I’ve found several reliable sources who refer to Event Sourcing by name, but very few actual implementations even today. Zimarev’s remains by far the most complete.

The Event Sourced system precipitates some properties I haven’t seen before. First, it comes with a natural audit log. Every action taken on the domain is stored in the event store along with our choice of metadata, most obviously the user taking the action. The event store is not queryable, necessitating the use of a projection into a readable form. While I’ve designed software using logical CQRS, this system is the first implementation I’ve seen that has different capabilities on the command and query sides, and allows many choices to fulfill these capabilities. Zimarev uses RavenDB + Event Store DB, a good choice today as they can both be deployed in cloud clusters to the AWS, GCP or Azure region of your choice. The specific choices for command and query side are quite involved themselves, and the subject for another article.

The next thing that jumps out at me is that the system is truly asynchronous. I had to move away from the idea that I present an object to the server for processing, and wait for some kind of result back (e.g. a database ID). Instead, the client does all of these id generations in advance and simply issues commands to the server to keep server state in sync. (Side note – look into ULIDs instead of GUIDs for universal IDs). This has its own challenges that must be understood. For example, the queryable database is now the “query” (“read”) side. However, there is latency between when an event enters the store, and when the read side is updated. This only matters if we insist on re-reading the object from the database to get something back. Universal id generation is important here, and the relationship between client and server is flipped on its head. The client holds the master state, and issues commands to the server to persist it.

Eventual consistency is a new challenge to developers. We should not avoid systems that are not immediately consistent, however. We simply need to learn how to build them such that we can truly fire and forget our commands, and be notified only if something goes wrong. The performance potential here is enormous: how much database effort is spent on joins and indexes to split object data into multiple tables, when we could simply store the data the way it is actually used? While some data (accounting, e.g.) seems to be better suited to tabular data, other data never needs to be anything but an object, and it is easiest to store it as such as a JSON document in a document database.

The biggest challenge that I face right now is the migration of the legacy system. It is simply too big to flip the switch on day 1. It needs to incrementally migrate to a new system, which means that the existing version must be able to write to the event store, and the new version must project back to the original database in addition to the document database. Of course, this is a lot of work that will be immediately obsolete, but we see this technique in bridge maintenance as well. If we wish to upgrade a bridge while allowing people to continue to cross the river, we need to build a temporary bridge first before closing the bridge for upgrades.

I don’t know what my performance expectations are at this point. Intuitively, it feels like a better design than using a relational database for absolutely everything. I know I no longer have to write error-prone mapping code to shove the data into an ORM. The more I work with document databases, the more I feel that relational databases are not appropriate persistence for object-based data. An interesting thought is that the databases will do less work. Writing to event streams is not compute-intensive work, nor is reading a selection of documents from a document database. The costs are already lower for the two databases, but I haven’t seen the resource requirements yet. The cost is simply the latency between write and read sides, which is handled by building the system asynchronously and making the application client-centric rather than server-centric. The projection, of course, is handled by the application server, so the latency can be managed to an extent by increasing the resources available to the application server.

Those are my initial thoughts about an Event Sourced system. With any luck, I’ll have a chance to design one soon as our company updates their applications to be cloud-native. I hope to see some tangible results this year.
Game Review – Diablo Immortal

June 5th, 2022

Diablo Immortal is Blizzard’s latest offering in the Diablo world of Sanctuary. For the first time, however, this game has been written ground-up for mobile. While you may think that this means it’s another phone-based “ARPG”, it’s anything but. While there is a phone app as well, the iPad app is a different version again, and Blizzard opened up a PC port on June 2. I’ve tried it out on all of the platforms, and offered my thoughts below.

Running on iPad Pro 2020 model, the game runs smoothly at 60fps and looks great. The iPad and iPhone versions are currently in their release states, while the PC version is in open beta. The game is best played using a gamepad, which is supported on all platforms. The phone UI is surprisingly good given the size of the screen, but I certainly wouldn’t want to have to use it for serious combat, or on anything smaller than the iPhone 12. Again, you’ll probably want a gamepad with a stand. The differences between the platforms are minimal, though. This is a true “play anywhere” experience.

I was myself skeptical of a game that targeted mobile when I first heard it, but having played it on iPad especially, it really is one of the best native games for the iPad and iPhone. And really, Blizzard hasn’t sacrificed much of the original game to make it a mobile MMO. Complaints in-game seem to mostly be related to the “Pay-to-Win” aspect, which I haven’t yet seen myself. You can buy a limited selection of in-game items that improve combat rating, but most of what I’ve seen has been cosmetic.

Once you get through the initial hand-holding, the combat starts to have a Diablo feel about it. A primary attack, 4 secondary attacks, and an “ultimate” ability make up your arsenal. If you like the previous Diablo games, you shouldn’t be disappointed by either the gameplay or the level of difficulty. For serious Diablo players, difficulty can be set once you surpass level 60 into the Paragon levels. It doesn’t take long to get rolling, and soon you’ll be blasting your way through hordes of Hell’s minions non-stop.

The story itself takes place between the events of Diablo 2 and Diablo 3, and you will see a lot of familiar friends, enemies, and places. The story itself centers around the fragments of the Worldstone that were scattered when Tyrael shattered it. Even a fragment of the Worldstone is a powerful artifact, and many ambitious agents of Hell are racing to retrieve them and sieze the power contained within them. You, of course, are the hero to stop them.

Many familiar gameplay elements are present: rifts and bounties. Immortal adds many familiar MMO elements, such as dungeons and raids (which are done in warbands of 8 players, a considerable improvement on the 4-player limit of previous games), crafting of various types of equipment and leaderboards.

The monetization of the game is 100% microtransactions. There are monthly benefits such as the empowered battle pass that give you additional rewards for progress through the game guide, as well as the Horn of Plenty, which provides additional login rewards. These are mostly convenience items, though some rarer crafting components and the crests required for Elder Rifts are also provided. I didn’t spend a lot of time in the store – there seem to be “troves” available after every major story point and cosmetic items galore. If you want to spend money, there’s no shortage of things to buy. But free-to-play is honestly just that. You won’t get hit with ads beyond the store ads at login and the notifications of new “troves” being available.

Overall, Blizzard has achieved their goal of making the Diablo universe available on both desktop and mobile platforms. I’ve found it quite enjoyable and immersive, and the social aspect has been thus far non-toxic, with very few spambots and truly objectionable conversation. There are, of course, the usual trolls, but the signal-to-noise ratio of the chats is pretty high. I’m not a particularly social player, but the game guide encourages finding a warband to accomplish the higher-level raid content, and it is relatively easy to join one. Without the massive size of the “newb” guilds on other MMOs, it feels like you can actually get to know people and not get lost in a sea of other “newbs”. A warband seems to be a good size, and the game provides many goals for them. Worth checking out for both newcomers and veterans to Diablo alike.

Modern Design Techniques – Event Sourcing

Game Review – Diablo Immortal