Event Sourcing, CQRS and Micro Services: Real FinTech Example • Hacker News Board

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

#41

Post by serbrech » Sat, Oct 18, 2025, 7:22 PM UTC

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.

CosmosDB has etags on every document

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

#42

Post by marcosdumay » Sat, Oct 18, 2025, 7:27 PM UTC

throwup238 wrote: post #2

> their MVP was not auditable and thus not compliant with financial regulations and also not scalable (high usage and fault tolerance). There it is. My automatic response to any questions about event sourcing is “if you have to ask, you don’t need it.” This is one of those situations where the explosion in complexity somewhat makes sense: when you need legally enforced auditability. Event sourcing is a really cool ar…

Yes. And that's usually anything that touches money or is limited by it.

But you don't need to decide to use it. The people describing the requirements will tell you, insist on it, and threaten you if you don't do it.

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

#43

Post by wiether » Sat, Oct 18, 2025, 7:28 PM UTC

geoffbp wrote: post #30

The message on his homepage doesn’t make sense right - it should say IT industry? > I am a Software Architect, Ex-Founder & AI enthusiast with over 8 years in the IT.

They appear to be ESL and if in Germany they use "IT" the same way we do in France, I can understand why they skipped the "industry" part.

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

#44

Post by aaronrobinson » Sat, Oct 18, 2025, 7:46 PM UTC

kccqzy wrote: post #40

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.

Fair. I was being flippant.

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

#45

Post by mattmanser » Sat, Oct 18, 2025, 7:50 PM UTC

javcasas wrote: post #19

throwup238 wrote: post #17

Earlier quoted context omitted.

The big caveat here is GDPR and other privacy laws. In some cases you need the ability to scrub the event store completely of PII for legal reasons, even if only to null the relevant fields in the events. Without preemptive defensive coding in your aggregates (whatever you call them) this can quickly blow up in your face.

What I have read about it is: encrypt PII with a client-depending key, do not post the key to the event system. When an erasure request comes in, delete the corresponding key. Now the data cannot be decrypted anymore for that client.

That is some serious architecture to put in place before you can even start using event sourcing.

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

#46

Post by ff4 » Sat, Oct 18, 2025, 7:54 PM UTC

They already had PostgreSQL (with its strong ACID guarantees) in place, yet the design introduces eventual consistency via MongoDB for reads—without a compelling justification. A DBA could have optimized those PostgreSQL queries to single-digit milliseconds, avoiding the added sync overhead entirely. Instead, it feels like unnecessary complexity was layered onto a proven double-entry ledger approach.

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

#47

Post by buster » Sat, Oct 18, 2025, 8:06 PM UTC

Event Sourcing seems like massive overkill for the stated problem. The core requirement is simple: "show account balance at any point in time" for regulatory compliance.

What specific audit requirements existed beyond point-in-time balance queries? The author dismisses alternatives as "less business-focused" but doesn't justify why temporal tables or structured audit logs couldn't satisfy the actual compliance need.

The performance issues were predictable: 2-5 seconds for balance calculations, requiring complex snapshot strategies to get down to 50-200ms. This entire complexity could have been avoided with a traditional audit trail approach.

The business context analogy to accounting ledgers is telling - but accounting systems don't replay every transaction to calculate current balances. They use running totals with audit trails, which is exactly what temporal tables provide.

Event Sourcing is elegant from a technical perspective, but here it's solving a problem that simpler, proven approaches handle just fine. The regulatory requirement was for historical balance visibility, not event replay capabilities.

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

#48

Post by mirekrusin » Sat, Oct 18, 2025, 8:15 PM UTC

r1cka wrote: post #33

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.

What if your correction renders subsequent events nonsensical?

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

#49

Post by alecco » Sat, Oct 18, 2025, 8:16 PM UTC

buster wrote: post #47

Event Sourcing seems like massive overkill for the stated problem. The core requirement is simple: "show account balance at any point in time" for regulatory compliance. What specific audit requirements existed beyond point-in-time balance queries? The author dismisses alternatives as "less business-focused" but doesn't justify why temporal tables or structured audit logs couldn't satisfy the actual compliance need.…

Not only overkill, but error-prone. I had to suffer to work on a massive financial system based in serialized Python objects. And expensive as hell.

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

#50

Post by coryvirok » Sat, Oct 18, 2025, 8:42 PM UTC

Not sure why there is so much hate on this thread. I found the post well written, insightful, and pragmatic.

Having built systems that process billions of events and displayed results, triggered notifications, etc in real time (not RTOS level, I'm talking 1 or 2 seconds of latency) you absolutely need to separate reads and writes. And if you can trust db replication to be fast and reliable, you can indeed skip distributed locks and stay on the right side of the CAP theorem.

Event sourcing is how every write ahead log works. Which powers basically every db.

Is the concern on this thread that they preoptimized? I thought they walked through their decision making process pretty clearly.