If you're about to implement a serverless architecture for an event sourcing based application, you are in the right place. This article aims at sh...
For further actions, you may consider blocking this person and/or reporting abuse
Hi,
Did you consider to use a simple queue system, that might help order the events? Also, why did you use dynamo db and not others, like mongo or postgres?
For money related interactions, did you consider to use transactions that also could solve the overdraft (and order of events) in first place?
The purpose of using Event Bridge is that you can have multiple consumers for a single event only based on filter rules which is not the case for queues that hide the event after a consumer consumes it. Also you would have to implement a FIFO for having events ordered and to be sent exactly once. The cost of a FIFO is much higher than what has been implemented here.
SQS messaging graph from Julian Wood
Also DynamoDB was prefered as SLQ databases because the access pattern used is simple enough to be implemented with Dynamo. Moreover a DynamoDB table is easier to setup and maintain. Now compared to MongoDB, according to this article, MongoDB needs to keep its working set in RAM to achieve acceptable performance. This reliance on RAM makes MongoDB too expensive for many use cases and especially for event sourcing because the event ledger stores all events for all users. And DynamoDB great performances are not dependant on the amount data stored.
But I’m sorry I didn’t understand the question about the money related interactions.
I hope you understand more clearly the choices made. Let me know if you have more questions about that topic.
"The projector can simply use the PutItem command of DynamoDB to overwrite the previous value only if the version incoming is strictly superior to current one stored"
I would stress the importance of this bit of information more on the post as without it the event enrichment strategy would not be possible. I had to reread the post about 10 times as i was too focused on other parts of the solution to realise what it was saying. I struggled to understand how the projections could handle out of order events even when enriched without it.
Anyway, great post. People too often strive for event driven systems that depend on FIFO SNS / SQS etc.
Hi there,
Just wondering, given every event contains the state of the aggregate, in which the aggregate was right after applying this event. What if the aggregate code changes (for any reason - bug fixing, evolving) and the shape of the aggregate state in subsequent events changes?
A real-life case we had:
We found a bug in one of our aggregate implementations - we incorrectly applied events due to the floating point operations, so we deployed a new version when we stoped using floating point operations, which resulted in how the state of the aggregate is represented. For us, if we'd been including the state of the aggregate into the events, we'd had to deal with this complexity in the projection (read) side.
Have you come across a similar challenge? If so, I'd be really keen to hear how you handled it.
Thank you in advance!
Vlad
Hey,
On the aggregate side you could implement some form of event upcasting (which you probably are already be doing in some way or another if you have have different versions of events)
If not, then Axon framework has good documentation on what upcasting is - docs.axoniq.io/reference-guide/axo....
On the projection side do something similar for aggregates, aggregate upcasting? It doesn't seem like much of a problem to me as you're already allowing aggregates into the query side of the application anyway.
Just a thought.