[erlang-questions] "actor database" - architectural strategy question

Miles Fidelman <>
Mon Feb 17 22:05:42 CET 2014

Ahh... thanks!  Now I know what to look for as a start perusing the 
riak_core architectural documents.

Re. a couple of your other points:

Michael Radford wrote:
> I was addressing exactly your second point: backing up and restoring actors.
> Since you brought up that point, it didn't sound like an "actor" in
> your model is 1-1 with an Erlang process for all time. So OK, you can
> checkpoint them and restart them. But what if you want the "actor" to
> continue to "respond to messages" when any single machine crashes?
> Maybe multiple Erlang processes on multiple machines can coordinate to
> provide a highly available representation of your per-document actor.

In some sense, I keep coming back to the model of paper documents - but 
just a little bit "smarter."
- I have a copy of the same document at the office, at home, in my 
briefcase, someone else has a copy
- updates can be distributed via copy machine and mail
- with paper, if one of them gets lost or stolen, there are other 
copies, but you lose marginal notes
- add a little "intelligence" and now copies can be synced (a la what we 
do with our smart phones and laptops) - with the sync logic embedded in 
the document rather than the environment (which is makes the actor-like 
rather than simply files or object-like)
- which does address one approach to backup - things are mirrored, if a 
node crashes, there are other copies around, it's easy to restore state 
(the only time things get lost is if one is running disconnected and 
things crash) -- though it becomes pretty inefficient if the power 
fails, or you want to reboot the machine, or what have you
> For the same reason, it sounds like you need reliable messaging, so
> that a locally-triggered change isn't lost if a machine crashes. So
> you may need to persist the update messages in multiple places.

I'm thinking that this is embedded in publish subscribe channels, with 
logs/archives.  I keep coming back to a USENET/NNTP model for both 
messaging and replication.
> Finally, you also mentioned "copies of documents" with "local changes"
> triggering changes in other copies of the documents. What if the
> locally-triggered changes conflict?

For this, I'm thinking that each document has an embedded change control 
system.  Akin to having one's own copy of a git repository. (The Fossil 
distributed version control system is a really nice model for this.)
> For example, a budget with a total, where any user can add or remove
> line items. To compute the current total, you need rules for resolving
> conflicting additions and removals of the same line item. Since you
> mentioned that these changes are "local" and you're sending messages
> among the document actors, it sounded like you had something like this
> in mind.

Exactly.  Which is one of the things that leads me to the actor model - 
embed the rules directly in each copy of the document, rather than in 
external logic.
> If any of these things are a concern for your application, I thought
> you might find the ideas behind riak-core helpful at least.

Thanks!  I'm going off to look now!

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

More information about the erlang-questions mailing list