Trilateral API for data sharing between microservice Bounded Contexts

August 9, 2021
Brandon Palmer Principal Software Engineer, Architect

We’ve moved from a world where most products were single large monoliths to one where there are a whole swarm of microservices within Bounded Contexts, all potentially trying to communicate with each other. Initial REST communication architectures solved some problems but also introduced many others. With the addition of Event Driven Architecture, many of those shortcomings have been addressed. This combination of communication methods has come together as a Trilateral API architecture.

How communication worked without a Trilateral API

As our monolith was decomposed into multiple bounded contexts, those contexts needed to communicate with each other. One easy model was to add REST endpoints which are internally accessible, thereby preventing neighboring bounded contexts from directly accessing remote databases. Adding all these REST endpoints solves some problems but then introduce others:

The Trilateral API

With a Trilateral API and using Event Driven Architecture (EDA), we can get around many of these issues. I first read about the concept of the Trilateral API from Architecting Cloud Native Applications

With a Trilateral API, for a given service within a bounded context, we have 3 main interfaces:

Services within the bounded context access their shared persistent storage backend (database, kv, etc)

This architecture solves many of the design changes we saw from earlier:

Live Use

Redox has moved many microservices to using this general model as we’ve moved to decompose our core monolith. We use Kafka/MSK for the event bus and have multiple services producing and consuming from the topics. We do certainly have a bunch of legacy services still using the legacy REST model but are moving away from that. Because many of our services all need the same data from one main bounded context, we’re moving to abstract away much of the topic based consumption and production to a DistributedCache.

Join Us!

Redox is constantly hiring and we have a ton of open positions all across the company. Come check our open positions and help fix healthcare!