Event Sourcing, CQRS and Micro Services: Real FinTech Example
lukasniessen.medium.com
Event Sourcing, CQRS and Micro Services: Real FinTech Example
1–10 of 70 posts
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#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 architecture that makes theoretical sense but the yak shaving needed to implement it is at least an order of magnitude more than any other design.
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#3I feel for these guys. The software downturn is steepening. A huge glut of talent with unsustainable comps. And years of toil doing stuff that, in the absence of being paid money for it, nobody would do and no one would care.
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#4> 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…
Yea I think that's a fair take.
If you peer underneath the covers of a lot of financial stuff, and it's effectively double entry accounting. Which is a giant ledger (or ledgers) of events
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#5This 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.”
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#6> INSERT INTO events (account_id, type, amount, timestamp)
VALUES (123, 'deposit', 100, NOW())
How would it work if they had to support intra system transfers? So one user balance should be withdrawn and another should get a deposit? That's not possible to do atomically with event sourcing right?
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#7> INSERT INTO events (account_id, type, amount, timestamp) VALUES (123, 'deposit', 100, NOW()) How would it work if they had to support intra system transfers? So one user balance should be withdrawn and another should get a deposit? That's not possible to do atomically with event sourcing right?
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
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#8> INSERT INTO events (account_id, type, amount, timestamp) VALUES (123, 'deposit', 100, NOW()) How would it work if they had to support intra system transfers? So one user balance should be withdrawn and another should get a deposit? That's not possible to do atomically with event sourcing right?
Create an event type for transfer with amount, source account and destination account.
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#9> INSERT INTO events (account_id, type, amount, timestamp) VALUES (123, 'deposit', 100, NOW()) How would it work if they had to support intra system transfers? So one user balance should be withdrawn and another should get a deposit? That's not possible to do atomically with event sourcing right?
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?
Re: Event Sourcing, CQRS and Micro Services: Real FinTech Example
#10> INSERT INTO events (account_id, type, amount, timestamp) VALUES (123, 'deposit', 100, NOW()) How would it work if they had to support intra system transfers? So one user balance should be withdrawn and another should get a deposit? That's not possible to do atomically with event sourcing right?
Any problem with event sourcing can be solved with more events (said semi-sarcastically).
In this case it’s XTransactionStarted, XTransactionDepositConfirmed, and XTransactionCreditConfirmed or something along those lines. External interactions tend to follow that kind of pattern where it tracks success/failure in the domain events.
The command side of CQRS tends to be the services that guarantee ordered events either via the backing database or with master-slave topology.