Hi Stefan, Systems like you describe definitely *are* implemented in terms of persisting events.
I would highly recommend these following videos / papers as a "holiday-read”: * Eric Evans (Dad of DDD) about modeling to such constraints WITH thinking of time and WITHOUT transactions http://www.ustream.tv/recorded/46744749 -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io On 25 December 2014 at 21:39:24, Stefan Schmidt (stsme...@gmail.com) wrote: Hi guys, I am currently prototyping a new app which involves transferring money between various accounts. On a very high level I have a system account (which is used to collect fees), one account for each member in the platform (many of them), and group accounts. Money needs to be moved on a frequent basis from member accounts (M) to group accounts (G) and the system account (S). Traditionally a transaction like this would be accomplished atomically: tx start - read M account to check for sufficient funds - deduct money from M account - add money to S account - add money to G account tx end I know already that the system account S will be involved in most of these transactions and eventually become a bottleneck in the platform. Another requirement in the platform is to have all money movements fully auditable, which is a very common requirement. So using event sourcing and CQRS comes to mind to solve this problem. Initially my thinking is to have a single persistent actor for each member account (M), a persistent actor for the system account (S) and a single persistent actor for each group account (G). Each will store events related to their respective accounts and offer different views (to keep the balance, monitor fraudulent behaviour, statistics, etc). In addition I would like to have a persistent actor to persist the overarching transaction events (lets call it TX actor), mostly for bookkeeping & statistics via its views. The idea is that a 'transaction' starts with this TX actor which then issues money transfer commands to all account actors involved (M, G, S), monitors their responses and either persists his own event of the successful transfer or issues a compensation commands in case something goes wrong). Because there will be a large number of members in the platform I would like to use Akka clustering where the persistent actors may live on different nodes. I have played with hash based routing and cluster sharding to address the single writers per account. My problem at the moment is to figure out how each transaction can become eventually consistent (say within a few seconds) in a clustered environment like this where there are multiple points of failure. Obviously I need to ensure that a transaction cannot leave the system in an inconsistent state and potential manual compensations are also subject to their own errors. I guess my question is if anyone has used Akka persistence / event sourcing / CQRS for handling financial transactions in a clustered environment? If so can you share some experiences or ideas, especially around ensuring (eventual) consistency? It seems like event sourcing is a good solution to overcome some of the bottlenecks which a SQL database will create (especially where there is one very contentious resource (account S)) but there is are not many reports out there where people have used ES specifically for money handling (perhaps for good reason ;)). Thanks in advance. -Stefan -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
