Hi I'm actually building the very same thing right now. I'm not finished so I couldn't give you a full answer but here are some points that I noticed:
"Registrator uses the read model of authenticator actor", I think this is a mistake. Keep a view of all state needed for validation in each Persistent actor. Try to remove direct dependencies between Persistent actors (request-response interactions) and keep them as small islands that can fail without cascading to other services. I'm using Cassandra so most of my updates will go that way. This is of course also a dependency (similar to an event bus which you can use as well) but I'm hoping that cassandra will be resilient to failure. Keeping all data needed for for validation in each Persistent Actor means you will have some duplicated state and also inconsistent state. So you need to consider what could happen in those "gaps", most of the time it is just fine to wait or you fake it. Example flows for registrator (accepts => persists) 1. register(email, password) => registered(email, generated userid, hashed password, verification secret, expiration time) => emails verification link with hmac-token => store data in three lists: allUserEmails, allUserIds and unverified registrations 2. verify email( hmac-token ) => email verified( userid ) => remove from unverified list and store in verified list 3. prepare password reset(email) => password reset prepared( userId, verification secret, expiration time ) => checks against verified list => emails password reset link with hmac-token => stores in password reset list 4. reset password( token ) => password reset => persist new password => remove from password reset list As you can see the Registrator keeps all the state it needs for it's own validation, but not any passwords. When the Persistent actor is created it will replay and get all the state needed again. If other actors are down at that time, no problem. Authenticator will be a persistent view that reads from the registrator event stream and filter out userEmail, userId and password. From the Registrator event stream it would sort out register, email verified and password reset to build up a list of user credentials. This means that Authenticator will eventually become in sync with registrator by just reading from the event stream. If the slight delay (default is 5sec) is a problem you can setup an event bus and publish an event there to either force an update from the event stream or just send the event. The point is that when you restart the Authenticator it will have all the data it needs to operate without depending on other running services (disregarding the event store). Authenticator can then in turn persists events containing login tokens (I'm using JWT so no session state held) to it's own event stream to be used for auditing purposes, fraud detection or single logout. One thing that still is a bit tricky is that a PersistentView can only read from one event stream. You will probably wish to read from multiple streams. But I suppose I can just have an actor system with multiple child actors that forward their events to a parent view. I'm hoping this will change (read something about it in here on the list). /Magnus Den fredag 3 april 2015 kl. 19:53:50 UTC+2 skrev Lukas Welte: > > Hi, > > I'm trying to figure out how one would model a user system (register, > login, update) with Akka persistence. > As I am quite new to as well Actors as well as Event Sourcing and CQRS > i'm going forward and backwards on ideas. > > Right now I would basically see one solutions: > Authenticator Actor (read), Registrator Actor (write), User Actor (read, > write): > > Registrator uses the read model of authenticator actor to validate the > registration and if succeeds creates a new user (event). Authenticator > listens to the user event and maintains the list of all current user's > (id+token oder something similar) in order to handle login. When > authenticated the User Actor is retrieved by id and inside the User Actor > everything concerning the user (information reads and updates etc) is > handled > > > But this solution does not feel quite right. > What am I missing? What would you're ideas be on modeling/implementing > such a system with Akka and especially Akka persistence > > Best, > Lukas > -- >>>>>>>>>> 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.
