Microservices isolation patterns

The Microservice architectural pattern has gained in notoriety since being formally coined in 2014. Many books and articles have been written on this subject, including in this blog. One topic however that can never be stressed enough is the importance of ensuring proper isolation of services and their data both within and outside bounded contexts. In this series, we’ll examine two ways of achieving this.

A quick refresher


Like i’ve stated before, you can think of microservices as small and autonomous services or independent processes that work together within a bounded context, communicating with each other over lightweight transports like HTTP.

The problem

Let’s say we’re building a social platform for Bike lovers to chat about bikes, wheels and whatever else they fancy. Let’s imagine as well that we’ve split the system into multiple services with HTTP endpoint:

  • Identity Service
  • Registration Service
  • Privacy Preferences Service
  • Comment Service
  • Basic Profile Service
  • Biky Posting Service
  • Liking Service
  • Friendship Service
  • Karma Indicator Service

Let’s also claim that alongside those different “Front-end services” we also have additional ones not directly accessible by consumers outside our internal network that do things like actually calculating a Biker Karma, monitoring breaches of Terms Of Service, etc…

All the Services

Let’s also assume you have your data defined in different isolated schemas/databases as such:

  • Account data used by the Identity, Privacy Preferences and Registration services
  • Profile data used by the Basic Profile and Identity Integration Services
  • Like data used by the Liking Service
  • Commenting data used by the Comment Service
  • Biky Post data used by the Biky Posting Service
  • Friendship data used by the Friendship Service
  • Karma data used by the Karma service

Some of the desired feature we want to implement are as follows:

  1. a Biker Karma needs to be recomputed whenever a user writes a comment. The karma score would vary based on whether or not the post being commented was that of a friend.
  2. a Biker Karma needs to be recomputed whenever a user likes a Biky Post
  3. users with a karma score less than -50 must receive an e-mail saying their account is temporarily disabled and are not allowed to post comments or bikies until a semi-automated validation of their activities is performed to ensure they did not breach the Terms of Service (ToS).
  4. users can limit comments on their Bikies to their friends only. Users can make that selection globally on their account privacy settings or on a post by post basis.

How would we go about implementing these features knowing that some of the information needed for each of them is dispersed across bounded contexts?

Let’s explore the first pattern