Measure Once, Cut Twice

Relative Cost of Distributed Architectures

Posted in architecture by steve on April 24, 2010

Applications that have both a desktop and a web version, often for online/offline use cases, force you to make a decision about whether you want to share or duplication the back-end code that isn’t dependent on the UI bits. If you have a nice, separable back-end engine component it is tempting to architect your application as two separate distributed components and treat the local configuration as a special case of that.

For example, when your core application logic is layered behind a REST API, why not just have mini-web server running on the client for the the desktop deployment scenario? The UI layer can manage this process transparently to the user.

The benefit is a single architecture to cover both the web and the desktop deployment scenarios — the trade-off is that you are building some fundamental latencies into your architecture. To put the costs in perspective, I tried to google up some rules of thumb on the typical latency of various types of calls. Here is a rough approximation of the relative costs:

method call — ~100s ns
synchronized method call — ~1000s ns
reflective method call — low ~10,000s ns
machine loopback — ~30,000-150,000 ns
local sub-network — 1-2 ms
internet — 10-100+ ms