You're actually advocating for an "actor model" yourself, you know :) The actor model of "actors as services" and "messages as API calls" that has practically

You're actually advocating for an "actor model" yourself, you know :) The actor model of "actors as services" and "messages as API calls" that has practically won in the real world. It also has the advantage of not being tied to one particular VM and it's polyglot by nature. It also isn't something that can be "scaled down" to language level constructs, and maybe that's for the best. Cells aren't made up of organs or of other smaller cells (mythocondria are quite exceptions, and the pattern goes only one level deep). I think the deeper truth here is that truly good architectures are emergent/evolved, not designed/architected... only problem is that they tend to emerge/evolve on time scales longer than the lifetime of most businesses, so you can't take the approach of "let's evolve the right architecture" and actually be able to ship anything on time. Don't know a "solution" for this other than staying humble and mentally flexible. Quite zen-ish ironical to think that the deepest wisdom we got so far in distributed may be the "PHP + MySQL" model of statelessness, short live isolated processes and business-valuable state kept in specialized storage systems :) The language you use for message processing is largely irrelevant as long as you keep the processing of messages isolate and transient (eg. throw away everything, including leaked/overflowed memory, after processing a message and replying - most systems besides PHP still fail at this!), the data store is also irrelevant as long as it support some basic transactional guarantees and you can easily back it up and import/export data from it to other systems better suited for other tasks.