What if your app had a Git history? | Issue #80


Hi there,

Most apps only store the final result: the current balance, the current inventory, the current status.

But what if you could track every change that led to that result?

That’s exactly what the event sourcing pattern allows you to do. Instead of overwriting state, you store a sequence of immutable events and derive the current state by replaying them. It’s like Git (kinda), but for your domain logic.

In this week’s video, I show you how to implement event sourcing in Python from scratch:

  • We start with a simple string-based inventory system
  • Add caching to avoid replaying events unnecessarily
  • And build projections like “most collected item” or “where items came from”

I also explain how this pattern compares to blockchain and Git, and when it’s the right (or wrong) tool for your project.


Have a great weekend!

Cheers,

Arjan


Do you enjoy my content on YouTube and would you like to dive in deeper?

🚀 Check out my online courses

My courses have helped thousands of developers take the next step in their careers. Check out these courses to help grow your skills and become a senior developer:

👕 Clean code and clean clothes

The ArjanCodes merch store features T-shirts, hoodies, hats, and more for the clean-code-obsessed. Careful though: you'll look dangerously professional while reviewing PRs.

👉 Check out the store here and grab something before your stand-up call starts.

Unsubscribe | Send by ArjanCodes

Wolvenplein 25, Utrecht, UT 3512 CK

The Friday Loop

Every Friday, you'll get a recap of the most important and exciting Python and coding news. The Friday Loop also keeps everyone posted on new ArjanCodes courses and any limited offers coming up.

Read more from The Friday Loop

Have you ever hesitated between writing a method or a property, and then just picked one because “it felt right”? That small choice actually carries a lot of design weight. In this week’s video, I explore when properties make sense and when methods are the better choice. I talk about what properties promise to the reader of your code, why setters should be used carefully, how this choice affects abstractions and Protocols, and where async fits into all of this. This video is also a good...

Most systems don’t start out needing CQRS. They start simple: create, update, list, dashboard. Everything in one place. Everything reasonable. Until read requirements slowly begin to reshape the system, often in subtle ways 🧩. In this week’s video, I show how that happens using a FastAPI app backed by MongoDB, and how Command Query Responsibility Segregation (CQRS) provides a clean way out once reads and writes want very different things. Along the way, I cover: separating command intent from...

Code can be correct and still be unpleasant to read. A lot of software design isn’t about what the code does but about how clearly it communicates the sequence of ideas behind it. In this week’s video, I explore the Fluent Interface pattern by refactoring a small animation engine in Python. I start with a clunky but functional API, then gradually reshape it until defining an animation reads almost like a sentence: move, rotate, scale, fade. Enjoy this deep dive into API design, readability,...