Can Event-Driven Architecture make Software Design Easier? (with Bobby Calderwood)

This week’s guest describes Event Sourcing as, “all I’m going to use for the rest of my career.” But what is Event Sourcing? How should we think about it, and how does it encourage us to think about writing software?

In this episode we take a close look at systems designed around the idea of Events, with guest Bobby Calderwood. Bobby’s been designing (and helping others design) event based architectures for many years, and enthusiastically recommends it not only as a system-design technique, but as a way of solving business problems faster and more reliably.

During this discussion we look at the various ways of defining event systems, what tools we need to implement them, and the advantages of thinking about software from an event-based perspective. Along the way we discuss everything from Clojure, Bitemporality & Datomic to Kafka and more traditional databases - all in the service of capturing real-world events and building simple systems around them.

–

–

#software #softwarepodcast #programming #eventsourcing #eventdrivenarchitecture #kafka #apachekafka

[MunzirSuliman]

I built a system that required multiple services to concurrently work independently yet needed to rely on an input from other running services and make decisions accordingly, building the app around events solved many many issues and made the app resilient, modular, and easy to maintain and also learn from events.

[Monotoba]

I've been revisiting software architecture paradigms and writing simple frameworks to implement them. Most recently, I'm working on a framework that closely follows Alan Kay's vision of OOP with a focus on standalone objects that only comminicate via messaging. I've found that enforcing messaging for all object to object communications has many benifits. This approach means method calls and return values exist only within an object. Kay was well ahead of his time. The decoupling you get is awesome!

[axosi]

I really enjoyed Bobby Calderwood in this episode, I'm currently building a event sourcing system and it gave me a lot to think through. I remember reading about the decider pattern but I didn't really internalize it but Bobby's way of explaining made a lot of things click for me.

[hyperlem]

Great interview! Appreciate the enthusiasm of the guest and coverage.

[bartkl]

Wow there was a lot packed into this one. Pretty challenging stuff, but I'm learning a lot here. Your channel deserves to be much bigger than it is :)

[gnschenker]

Great podcast. Many thanks for it. As an early adopter of DDD and event sourcing (ES), I can only confirm most or all of what was said in the video, about the benefits of ES. We were early adopters of Greg‘s event store DB and I have written my own various implementations of an event DB on top of Oracle, sql server and even the file system. It’s been a lot of fun.
But luckily you guys didn’t stop just at ES but touched (although too briefly) the design part. Yes, indeed, EventModeling is a great methodology to model a complex system and to lower the cognitive load by concentrating on the flow of information and get that predictability back.

[oscbit]

## Main takeaways

- Event sourcing is at it's core a append-only file with an I/O handler like Kafka.
- The immutable log is the state as a stream of events, accessed though a left fold, accumulating the state changes and producing the current state.
- While both message passing and event handling pass data between components, message passing involves sending messages to trigger actions or communicate between components—event passing only captures state changes.
- There is no query or usage pattern opposed, the behavior of a system can be derived from it's output (although often still implemented for optimization).
- There is still techniques like optimistic concurrency control needed for managing faults.
- We still need a write-ahead log + some mid-tear state manager, thats building indexes for intermediate states.

[clarkd]

I have used transaction files (what was the change) in OOP code and every other type of language for more than 40 years. Any code base can adopt an event style without any difficulty. Forcing all changes to be recorded even when there is no purpose, is similar to programming as a religion. I program almost exclusively in an event style but I also just use the current state whenever I don’t need to track those changes.

[dadlord]

Dudes are basically discussing multiplayer game networking and it's"prediction" problem.

[makeitreality]

In the customer journey domain with online sales, customers demand certain events. And they're not getting them. Knowledge in this area is worth billions.

[ActualJosiahPreston]

Regarding domain blindness around the 12:00 minute mark, the domain blindness happens because keeping an event ledger without using event sourcing (with separate read/write models) is a big pain in the butt. lol

[sadasdasd]

Ignore the content, I like your voice

[bobbycrosby]

I'm curious as to how event sourcing deals with GDPR - it seems like that would be particularly tricky if the whole point is to have an immutable log.

[RoamingAdhocrat]

I nearly clicked off when I heard "We're standing at the dawn of an AI revolution" (we're standing on the brink of the AI bubble bursting) - but I quite like the idea of a small-scale LLM that runs locally and makes _informed, verifiable_ statements based on your own event streams

[johnsalverda]

Event-driven software can be hard to write. To be honest, last time I tried was in C++ in win nt 4 for an amusement park ride. Basically, it was a PLC - PC data translation program. Events were not expectable.

[bloody_albatross]

How do these systems cope with when you really need to delete something for legal reasons? Like a user requests their data to be deleted, but that should of course not remove the views that user gave to a video. Or differently said, when you can't keep that of a detailed log for legal reasons can you still use this?

[landspide]

The industry is filled with interesting ebs and flows. Millions of dollars chasing the next big thing in enterprise software, that is, building tomorrow's painful legacy, one exciting relevation (aka. dependency) at a time. Titan's "betting the company" on ideas that fizzle only to switch focus, ultimately contradicting the depth of the bet in the firstplace. Rise repeat :)

[makeitreality]

Events are mainly useful for multiple processes. They add unnecessary complexity to something that can run in one process. But for recording multimedia, for example, I have one thread handling actual buffering and writing to disk. And another thread drawing the VU meters. An event triggers 10 times per second to update the sound level value. The actual drawing of the display is deferred the background process so it synchronizes with the screen drawing, does not cause latency, or "tearing". Without an event, the logic becomes error-prone. And it's possible to drop audio frames or freeze the application waiting for some unforeseen condition such as a bug in the meter display. With an event, the thread running the display can freeze but recording can still continue without losing data.

[eliseulucenabarros]

when is come out the video about the Odin Programming Language ? hehehe, sorry, just asking

[dadlord]

Events are obviously a good thing to listen for in architecture as everything that happens spontaneously- is an event. Still looks like ECS is just better even for events. It's just a tag added to an entity that could hold any data and that data (components) could get extended in a pipeline of systems execution with another components. And so OOP with it's jumps in RAM not getting fixed by events. But there is no way to get out if OOP domination. Technically events are making your program even worse in terms of performance as decoupling in OOP means more pointers in RAM placed in random order. It sucks to the point where your performance testing is never be valid as each time you run the test - everything is placed randomly again and so the program could run much faster or much slower all the sudden.