Your application's memory

In the first issue we talked about events as something that can be seen as something similar what accountants do. But please, let's no longer talk about accounting (at least for now).

The important thing to remember: If you write something down, you will remember it. And if you possibly could writing everything down, you would be able to recall every single thing at any given time.

It would take a while to get through all your pages, building something like a temporary state in your brain, but after a while you would get there.

That "while" and that "temporary state" highly depends on the thing you try to remember.

For example: If you would write down everything you did today and took that event log to answer my question: "How many times did you wash your hands today?", it would make sense to skim through all your "I washed my hands" events and simply do a count on them.

But what if I asked you something that causes a little more computing? For example: How long did you sit around like a couch potato?

You would need to search for the following events:

• Left the bed
• Sat down on my office chair
• Got up from the office chair
• Laid down on my couch
• Got up from the couch
• Sat down for dinner
• Got up from dinner table

You would not only need to search for the events - you would also need to calculate the time between the "sitting down" and "getting up" events and sum that time to answer my question.

You sometimes even need to have some kind of state in your mind, if events contain additional information or do not reflect the whole picture completely.

What if I asked you to answer: How long did you sit around at home? You would need to consider a few more events:

• Left the bed
• Left the house
• Sat down on my office chair
• Got up from the office chair
• Went home
• Laid down on my couch
• Got up from the couch
• Left the house
• Sat down for dinner
• Got up from dinner table
• Went home

In that case you would also need to track the state of your location of that time. Obviously, you only need to consider the time you were in bed and netflixed on the couch.

You can imagine that that temporary state you need to track can easily become unmanageable. And of course, machines can solve that problem easily. But that is not the point.

The point is...

The point is to identify things that form a thing (what a great sentence). Of course, you would never ever write everything down. And when it comes to your application, I would not recommend to do that.

You need to identify what to store as an event and why. Keeping in mind that we cannot modify those events, we need to keep an eye on the amount of data we are storing. Because as we are not allowed to modify our event log, we are also not allowed to delete records (well, that is not entirely true, but we will come back to this later).

So the key is to identify things that are worth storing. And this highly depends on your application.

So let me introduce my own litte side project: A tool to manage servers (like that one this publication is hosted on, by the way).

I know all the cool concepts like GitOps and so on - but this never felt natural to the average web agency or even the hobby blogger. But I wanted to provide a way to track the server's state and provide a possibility to rebuild a server to any given state the server had over time.

Deleted a database user? Not a problem, just revert that change.

So what is it that I should save here?

So if I want to apply the state of 11-18-2025 14:15, the result would be a server with one website.

If the user bought the premium subscription is not of any interest when it comes to the server's state. Same is true for the fact that the user logged in before.

Don't get me wrong: The information that the user is subscribing to my cool app is important. Based on that I can decide if I want to allow the user to perform actions. Same is true for the login status. But both have nothing to do with the state of the server. And this is the one thing I care about (for now).

The hard thing to solve is not storing events that can later be deployed but identify the small pieces of your application that can benefit from such huge memorized data.

How I did that, where I failed and how I (hopefully) overcame issues related to bad decisions I made in identifying those borders, I am going to tell you in the next issue of this eventsourcing journey.