Hi there Sudhi!

For a highly scalable distributed service that I'm building, I'm considering 
using event sourcing pattern. 
Yup, that could be a good match, let's see what you need.

I'm planning to use Akka clustering with persistent actors for this 
application. I have a few questions related to event sourcing.
Yup, that's what they provide :-)



Are there scalability concerns with event sourcing, for e.g., when there are 
several millions of events in the system ? 
EventSourcing actually is applied for systems where you need to scale for crazy 
amounts of writes :-)

So to answer your question - it is much easier to scale a CQRS based (using 
EventSourcing) system than a system that has one datastore that does all the 
read and write ops at the same time. Using events and CQRS you can detach the 
writing from reading and this store both in their "best fit" datastores - i.e. 
something that is good at taking writes and something else that your analysis 
will love (i.e. SQL based etc).



Has anyone used event sourcing in scale in production ?
Sure, lots of use over the last years.

The CQRS Journey "book" by Microsoft actually has a number of case studies, so 
I'll refer you to those: https://msdn.microsoft.com/en-us/library/jj591557.aspx

Of course, there's also quite a few of our customers using this technique (with 
Akka Persistence), but not sure which names I can drop :-)



What is the best way to handle schema changes in akka persistent actor ?
We're in the middle of collecting all the best practices we've seen for the 
last year or so into a document that will be part of the official akka docs 
that answers exactly that question:

https://github.com/akka/akka/pull/18084/files#diff-619aa26f60fa5ea430bd6cf255253bbaR1

It's a PR at this point but should be finished by the end of this week the 
latest - you can skim it already.



In practice, what is the best way to handle data corruption ? Is it through 
snapshots ?
Yes, snapshots, and backups of your datastore of course. That's not really an 
Akka specific question though.

For any Database you should apply what it recommends to avoid data corruption 
(usually backups and replicas).

What are the best practices to purge old events without impacting recovery ?
Delete "up until a sequence nr". Never delete "just this one", that doesn't 
really make sense.

In general design for *not deleting* events though, learn to life with it (disk 
is cheap!) as the data may be super valuable in a year or so :-)



Hope this helps, happy hakking!

-- 

Konrad

http://akka.io

-- 
>>>>>>>>>>      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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to