Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Event Sourcing, CQRS and Micro Services: Real FinTech Example

lukasniessen.medium.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#31

Post by javcasas »

saxenaabhi wrote: post #21
javcasas wrote: post #18

Earlier quoted context omitted.

Any modern DB with a WAL (write ahead log) is an immutable event system, where the events are the DB primitives (insert, update, delete...). When you construct your own event system you are constructing a DB with your own primitives (deposit, withdraw, transfer, apply monthly interest...). You have to figure out your transaction semantics. For example, how to reject invalid events.

> Any modern DB with a WAL (write ahead log) is an immutable event system, where the events are the DB primitives (insert, update, delete...). Agreed, I just wish apart from WAL they also had versioning as first class and their update api required clients to pass the version they have "last seen" to prevent inconsistencies.

On most SQL databases, you can put CHECK constraints on columns so that the database rejects events. But this is controversial, as people don't like putting logic on the DB.

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#33

Post by r1cka »

nateroling wrote: post #5

This made me do a double-take. Surely you would never do this, right? It seems to be directly counter to the idea of being able to audit changes: “Event replay: if we want to adjust a past event, for example because it was incorrect, we can just do that and rebuild the app state.”

The argument I've always heard for this was issues with code, not the event. If for a period of time you have a bug in your code, with event sourcing, you can fix the bug and replay all the events to correct current projections of state.

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#34

Post by rawgabbit »

sfjailbird wrote: post #23

Traumatic flashbacks to 2017. Glad we moved on from this nonsense. Still dealing with the wreckage, though. Event sourcing is a terrible idea that may be useful for some incredibly niche scenario.

What did you find to be the most problematic?

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#35

Post by rawgabbit »

risyachka wrote: post #32

It kinda sounds like all you needed was a ledger, otherwise didn’t get why would you use CQRS.

For me the most important ideas is an immutable ledger and isolating the primary OLTP database from the secondary support services. Reporting, user management, and notifications etc. can be satisfied with a stale copy of the transactional data.

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#36

Post by herval »

saxenaabhi wrote: post #9
herval wrote: post #7

Earlier quoted context omitted.

Do you mean inter-system? Intra-system would mean on the same db, so a simple transaction would do. For inter-system consistency, you’d probably need a reconciliation mechanism or some kind of 2 phase commit

I mean a bank account sending money to another bank account. That would be 2 events(one withdraw and one deposit)? But if I'm downstream consumer consuming the event log and computing the state from that, if for some reasons I receives only first event the state computed would be invalid and not represent the real state of accounts?

It could be one event with two database rows inserted, CQRS doesn’t have to map 1:1 to db entries. But in general, these kinds of systems are more complex than 1 or 2 writes, so relying purely on transactions isn’t very common

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#38

Post by zigzag312 »

sfjailbird wrote: post #23

Traumatic flashbacks to 2017. Glad we moved on from this nonsense. Still dealing with the wreckage, though. Event sourcing is a terrible idea that may be useful for some incredibly niche scenario.

Data sync is one scenario where it can be useful.

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#39

Post by marcosdumay »

javcasas wrote: post #18
saxenaabhi wrote: post #14

Earlier quoted context omitted.

Not speaking about their case, but I think some cases a "versioned mutable data store" with a event log that lists updates/inserts makes more sense than an "immutable event log" one like kafka. Consider the update_order_item_quantity event in a classic event sourced systems. It's not possible to guarantee that two waiters dispatching two such events at same time when current quantity is 1 would not cause the quantity…

Any modern DB with a WAL (write ahead log) is an immutable event system, where the events are the DB primitives (insert, update, delete...). When you construct your own event system you are constructing a DB with your own primitives (deposit, withdraw, transfer, apply monthly interest...). You have to figure out your transaction semantics. For example, how to reject invalid events.

DBs only work because the events are artificial and nobody cares about what's written in them.

And DBs are not really CQRS because the events are artificial and don't have business data that people are interested in keeping.

Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example

#40

Post by kccqzy »

aaronrobinson wrote: post #37

The answer to Event Sourcing and CQRS is no.

The answer is rarely so clearly cut. This is a natural extension of the bank system of having both account balance and account transactions. How would you feel if the bank only knows your account balance but not transactions? It has its uses. It's just a bit overused in places where it's unnecessary.
Post reply on HN