I put together a project to document an architectural discipline I call "Lateral Isolation". The core idea is simple: preventing direct communication between peer services by requiring all interactions to pass through a controlled boundary.
I am not claiming this is a brand-new pattern—it is essentially Information Hiding and the Acyclic Dependencies Principle applied strictly at the service level. However, I wanted to provide more than just theory.
My GitHub repository includes runnable code and an ArchUnit test that physically proves the isolation holds and prevents the inevitable "just this once" dependency sprawl.
The Trade-offs (The "Tax")
I have explicitly documented the costs because architectural rules are never free:
- Latency: Enforcing this means accepting a 5–10 ms latency tax per hop.
- Centralization: A shared boundary introduces centralization risks.
Because it is not meant to be a blanket rule, I also included a framework for deciding when to enforce it versus when to skip it.
Looking for Critique
I am looking for this community to poke holes in the logic. Where does my "decision rule" fall apart? I would appreciate any blunt feedback or edge cases I might have missed.
You can check out the runnable demos and the full logic here: https://github.com/vijayagopalsb/isolation-tax
Top comments (1)
I'd love to hear how other backend engineers handle this specific trade-off. Accepting a 5–10 ms tax per hop is an easy choice for low-frequency paths, but where do you personally draw the line when it comes to your latency budgets? Do you have a strict threshold where you abandon the 'shared door' and allow direct peer-to-peer calls?