Event Sourcing : what could possibly go wrong? by Andrzej Ludwikowski

Подписаться 156 тыс.

Просмотров 14 тыс.

50% 1

Yet another presentation about Event Sourcing? Yes and no. Event Sourcing is a really great concept. Some could say it’s a Holy Grail of the software architecture. I might agree with that, while remembering that everything comes with a price. This session is a summary of my experience with ES gathered while working on 5 different commercial products. Instead of theoretical aspects, I will focus on possible challenges with ES implementation. What could explode (very often with delayed ignition)? How and where to store events effectively? What are possible schema evolution solutions? How to achieve the highest level of scalability and live with eventual consistency? And many other interesting topics that you might face when experimenting with ES.

Наука

Опубликовано:

12 окт 2022

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 13

@basilthomas790 Год назад

Excellent presentation and best by far PRACTICAL discussion regarding how to implement Event Sourcing that I have viewed anywhere!!

@TheLavaBlock Год назад

Very compact and comprehensible summary. Thank you for this

@dolibert 6 месяцев назад

Really thanks for giving an overview on architecture variants and stack options! Great to have your opinion on that

@user-mq9gr5zz6o 10 месяцев назад

Brilliant presentation Mate

@wo11ucks Год назад

Where can we find slides?

@Strannik20111 Год назад

The main point I've learnt from this talk is that event sourcing is just funny)

@omerorhan80 Месяц назад

what about sensetive data? for example credit card information. When we keep events they will always be readable, so isn't that a safety issue? So we shouldn't use ES for that kind of use cases?

@sarwanhakm7517 4 месяца назад

thank for the presentation but man how do you replay events through the event bus for a new read model or just prepare a brand new read db? this doesn't sound like an ES system to me where Dual-Write Problem is introduced that causes inconsistencies

@KhaledKimboo4 3 месяца назад

Every presentation ignore the elephant in the room, state consistency is crucial not because the client needs them but your commands and domain handlers requires them, I say +90% of state query (read model) are fetched by other commands to check, verify, decide... before storing the event, hence es after a while you'll be forced to implement atomic state persistency . Event sourcing is like walking on you hands to better see the floor.

@mehrdadk.6816 Год назад

The worst thing to do is to use EventSourcing that relies on database. Imagine that you come up with 90 million events, then good luck with performance issue on start up

@mehrdadk.6816 Год назад

@@VitoVicoVito it depends, for this case it's better to use EventSourcing and Snapshots at the same time, however this is really hard to implement. One another case is to use Kafka Streams which has internal state-store. Flushing old events after snapshot is also possible

@casiowatch125 Год назад

See Akka persistence for an "out of the box" event sourcing+ snapshotting library. But you basically snapshot your state after x number of events. Then when rebuilding state, you take the snapshot as your base state and replay events on top of that instead of starting from the genesis event

@casiowatch125 Год назад

Oh it's already discussed in the talk