3 ms·
I think the belief is that if all your state is held in a transactional database, then your actors don't have any state in them and at that point it's not clear
by thu2111 7y ago
I think the belief is that if all your state is held in a transactional database, then your actors don't have any state in them and at that point it's not clear what they're doing with messages that the sender couldn't just do directly themselves by talking to the database.
My own experience with Akka style actor designs has been pretty poor. The problem is you lose the notion of a cross-machine call stack. Actors just have mailboxes and process inbound messages/outbound messages, which means you have to maintain state machines yourself and/or handle re-entrancy. Lots and lots of bugs in designs like that.
On the other hand, simply doing blocking RPCs across services where the RPC framework handles re-entrancy and stack consistency for you, it doesn't have that issue. That's how services like Google search are built. They shard across many machines vs talking to a database directly primarily for performance or to enforce team boundaries, not as part of an over-arching architectural design pattern.
- dnautics 7y agoYeah probably 90% of actors in elixir hold state that is relevant to a connection status. Think, tcp state machine or http connection state. It is veeery nice to have a state machine back your inbound http long poll or websockets connections if you want to do serverside rendering or serverside content streaming etc. The other case is when you're doing something cqrs-ey where you can have competing load balances requests and you need to make sure that writes are logged, committed, then executed, and reads are cached. You should use an actor for that but ultimately your data will reside in a database.