Working on my next programming-related video. I had annual leave I needed to use, or loose. So, decided to take a break from everything and focus solely on this for a full week. No other commitments. Having so much fun!

"We're doing Event Sourcing with Kafka!" Maybe. Depends how you're using it. Kafka can be an event store, but I know several teams using it just for streaming, not sourcing. Looks similar, but it's not the same thing! #EventSourcing #Kafka

Your projection is broken. This WILL happen. Plan for it! Common strategy: 1. Build new projection (ProjectionV2) 2. Fill it from events 3. Switch traffic once caught up 4. Delete old projection Projections are disposable. They’re just views of events.

Your Process Manager (thing coordinating multiple services) can ITSELF be Event Sourced! Events IN: OrderPlaced, PaymentReceived Events OUT: ReservationRequested, ShipmentScheduled Orchestration with full history and testable like any aggregate It's events all the way down

Year 1: OrderPlaced {orderId, customerId, items} Year 2: Needs "shippingMethod" But, old events? 1. Upcasting: transform old events on read 2. Weak schema: new fields optional 3. Multiple event types: OrderPlacedV2 Each works: - Weak schema = simple - Upcasting = control

The checkpoint problem: Update projection → SUCCESS Save checkpoint → CRASH Checkpoint is now behind the data. Restart = reprocessing. Fix: Store checkpoint with projection data, update both in one transaction. Either both succeed or both fail. No inconsistency.

Make projections idempotent Your projection processes event 458,295 and crashes before saving checkpoint. On restart it processes 458,295 again. If that duplicates data, you have a problem. Already processed? Skip it or make replaying give same result. Design for safe replays

Your projection crashes halfway through 1M events. When it restarts, where does it begin? Checkpoints solve this: periodically save "processed up to event 458,295" Restart resumes from the checkpoint. No checkpoint? You replay from the beginning. Trade-off: checkpoint frequency vs replay cost.

Medical records are append-only. Doctors don't UPDATE past entries, they add corrections. March 15: "Patient reports knee pain" March 16: "Diagnosis: sprain" March 20: "Corrected diagnosis: torn meniscus" All three facts are true. All three stay in the record. Just like Event Sourcing.

Internal Events: - CustomerAgeCalculated - InventoryReserved Private domain implementation. Can change anytime External Events: - OrderPlaced - PaymentReceived Published API. Version instead. Exposing internals creates distributed coupling. Keep them separate.

It is on YouTube but it was in the time of COVID so is an on-line teams type presentation thing... youtu.be/eD7ls4KynRo

Common Event Sourcing mistake: multiple aggregates in one stream. One stream = One aggregate Customer[123] stream → CustomerRegistered, EmailChanged, AddressUpdated Order[456] stream → OrderPlaced, ItemAdded, OrderShipped Different streams. Different things.

You can have the event chain organised as a workflow (based on an event stream) identified by an unique identifier and pass that identifier to the individual processes as a correlation id...and have them write back their doings to that event stream. Thus your workflow is its own log.

I'm an advocate for giving every event a Correlation ID copied from the command that caused it. OrderAccepted → OrderPaid → OrderShipped All share CorrelationId: "ABC123" Now you can... 👇

Your data team wants to build reports and dashboards but your events live in an append-only log... They want a relational schema. Solution: project events into a dedicated reporting database! Why? 👇

How do you handle two processes acting on the same thing in Event Sourcing? Optimistic concurrency with expected version: 1. Load events from stream (version 67) 2. Process command, generate new events 3. Write with expectedVersion=67 And then... 👇

Event Sourcing requires a mental model shift. "But I need to DELETE something!". Here's the reality: you don't delete events. You record a NEW event that something was deleted/cancelled/revoked. OrderPlaced → OrderCancelled Both facts are true. History doesn't have an undo button.

Event Sourcing tests double as documentation. Given: [OrderPlaced, ItemAdded] When: RemoveItem Then: [ItemRemoved] This reads like a spec. It IS a spec. Your tests become the living documentation of your business rules.

A Projection is something that converts your event stream into state for reading. Kinda like a database view, but better: - You can have dozens of them - Optimised for specific queries - Rebuild anytime from events - Different databases even

Just gave a talk about this at #dev2next and it’s incredibly powerful yet not very complicated once you get in the right mindset. ted.dev/talks #Java #EventSourcing #cqrs

"How do you query an Event Sourced system?" You don't. Not directly. This is where CQRS (Command Query Responsibility Segregation) enters. Commands write events → void return Queries read → no mutations Separate concerns. Separate models. Separate scaling.

Traditional approach: Save the structure, lose the story Event Sourcing: Save the story, derive the structure Your domain object's structure becomes transient. Storage format ≠ Application format

Want to understand Event Sourcing? Try: 1. Write every FACT that happens in your system on sticky notes 2. Put them on a wall 3. Group related ones together You'll have hundreds. That's your event model. (this works great even if you DON'T use Event Sourcing)

An event is a fact something happened in your domain. Named with past tense verbs: `CustomerRegistered` or `OrderPlaced`. Events are immutable, which makes sense when you think about it because you can't change the past. This principle is critical to Event Sourcing

I've only just discovered pm2 Why didn't anyone tell me about this before!? pm2.keymetrics.io

Storing your current state is like taking a photograph. Event Sourcing however is like having the full video. This is why it can be hard to know WHY data changed when you only store WHAT has changed.

Have been doing a lot of cool stuff lately. Lots of work with Integration Events, a lot of C# and .NET, event sourcing and CQRS. Yesterday I was the first time in a long time I used “completeness guarantee” in a discussion. Enjoying things, very much, at the moment.

My little hobby channel just turned 2 years old and my most successful video just reached 100k views. I've also just started working with my first brand! Best thing - it's all fun. No stress. No pressure. Just pure enjoyment.

The best metaphor for 'Single Point of Failure' must be the Death Star.

Easter egg on my Pipe Operator post: Both the donut preview and code examples are projections of an event stream. You were able to see the event stream if you knew what to click. It was a little too hidden, so now it's automatically visible at the bottom of the post if the stream isn't empty.

If all goes well, I'll be doing a lot of #dotnet over the next few months! 🤞

Little moments like this make all the effort worth it. Grateful for the kind words and the reminder of why I love making content! 🫶

Why should you model your events to be immutable? To prevent stuff like this: acairns.co.uk/devlogs/prof...

I pretend to be ok with this Lighthouse score, but... I'm really really not. 😅

This tiny graphic on my site has, by far, the largest file size. It was rushed. Started as SVGs, then animated on an html canvas, before being converted into an animated gif. Such a waste. It's time to put my post-holiday "get shit done" energy to good use!

I think I just convinced my EM that everything is a workflow. Productive morning, indeed!

This little guy will soon replace one of the largest assets on my site:

This demo is incredible: codepen.io/kiranpate1/f...

Created lots of visual components for videos in the last year or so. Intention was to reusable them in articles - but it's not working. Gonna try html, css and js and see how far I can get keeping it super simple.

Drafted 3rd post in my devlog. It's a war story on debugging mutable events. I did promise to share the challenges that come with decoupling a bounded context from a monolith! 😅 Pending employer review. Might be delayed by the holidays... but it's almost there.

The Pipe Operator will make a significant improvement to the readability of our #php code. Composition will never look the same. Check out the difference with an interactive example:

Very pleased with how this article is turning out! Looking forward to publishing it.

Finally! 😅 I've solved the pain with dynamic code blocks without breaking syntax highlighting.

40 minutes away from completing my first 16 hour fast in over 2 years. Small but important step in a new routine.

"Do what you love for a living and you will never work a day in your life" Terrible advice. Can't find anyone willing to pay me to watch kayak/canoe trip videos.

Thank you for subscribing! 🫶

Interested in extracting a service from an existing monolith? One approach is using Branch by Abstraction: acairns.co.uk/devlogs/prof...

Composite is a Design Pattern that can be used to treat single objects, and collections of objects, in the same way. Here's an example:

Have you ever wondered how strategy games like Red Alert 2 manage hundreds of units on screen without crashing? The secret is the Flyweight Pattern:

The Adapter Pattern is useful when you want to own the interface you want to use: