I suspect that getting our developers to embrace not only this new architecture, but also the new paradigm of functional programming is a bridge too far. Regar

I suspect that getting our developers to embrace not only this new architecture, but also the new paradigm of functional programming is a bridge too far. Regarding the "full-bore bus" question, I see it being that way for two reasons: 1. Distributed architecture. I think that the way to foster simple deployment of updates services is making them distinct deployable units, and the most obvious way to do that is to put each on its own cluster of servers - although in most cases this is way overkill in scale. And I think that if the services are on different machines, that pushes away from a really simple approach like your idea of files, toward something more sophisticated. On the other hand, perhaps there's a good way to let the services be co-resident by using docker, which I don't yet know very well. 2. Capacity. Although most of the system isn't too heavy, I've got a couple services that are used ubiquitously, and probably do need serious high-performance. First, the legacy system at peak is handling about 25 product pricing queries per second (our pricing is customer specific and based on near-time availability from suppliers). Second, we have not just localization of text, but customer-specific text, so every bit of text everywhere needs to come from that customization engine, although I suspect that this may wind up being addressed more as caches at the UI layer.