skip to content

Communication & Data Management

11 roadmaps34 questions

How services actually talk and who owns the data: synchronous versus asynchronous styles, gateways and BFFs, contract versioning, and keeping data consistent when nobody shares a database.

part ofMicroservices architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

At an organization with dozens of independently-deployed services, what practices let a platform team enforce contract compatibility and coordinate breaking changes across teams, without a central team reviewing every API change by hand?

level: principalimportance: should knowfreq 40%

basics

~20 s

Automate the checks instead of relying on manual review: run compatibility checks in CI, block deploys that break a registered consumer contract, track who's still using an old version with telemetry, and set an org-wide deprecation policy everyone follows.

open as a page

You're designing the communication for a saga spanning five services with compensating actions on failure. Under what conditions would you choose choreography versus orchestration, and what does each cost you in observability and evolvability as the system grows?

level: principalimportance: nice to knowfreq 40%

basics

~20 s

If the steps are simple and mostly independent, letting each service react on its own (choreography) keeps things flexible as you add more services. If the steps are tightly sequenced with real error handling and rollback logic, having one coordinator (orchestration) keeps the whole process understandable as it grows, even though that coordinator becomes something everyone has to touch.

open as a page

Under what circumstances might a team deliberately choose NOT to fully split a database per service, or to relax strict data ownership boundaries, and what risk are they accepting by doing so?

level: principalimportance: nice to knowfreq 40%

basics

~20 s

A small team with just a couple of services and no need for independent scaling might keep things simpler by sharing one database for now, accepting that they'll have some hidden coupling that could cause pain later if the team or system grows.

open as a page

Because a saga is a sequence of independently committing local transactions rather than one ACID transaction, other operations can observe and act on data mid-saga. What isolation anomalies does this create, and what techniques mitigate them without resorting to a distributed lock?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

While a saga is still in progress, other users or processes can see and act on the half-finished data, which can cause weird bugs like double-spending a discount or acting on data that later gets reversed. Teams fix this with tricks like marking records 'pending' so others know to be careful with them, instead of using a database-wide lock.

open as a page

showing 31–34 of 34