Microservices Coupling Matrix
Show service-to-service coupling at a glance. Drop the result into your next architecture review.
Software architects mapping a microservices system inevitably reach the moment where someone asks "which services talk to which?" — usually mid-incident or mid-redesign. A microservices coupling matrix captures the answer rigorously: each service appears as one item, each cell encodes whether two services must be tightly coupled (shared transactions, synchronous calls), should be loosely coupled (async events, eventual consistency), or must be kept apart (different security zones, separate compliance boundaries, no shared infrastructure). Compared to a directed dependency graph, the matrix is more compact in a deck and forces a deliberate yes/no decision for every service pair rather than letting unintended couplings sneak in.
This tool gives software architects a fast, browser-based way to build that matrix for an architecture review, a refactor proposal, or a design-doc appendix. Start from the Microservices Architecture template — pre-loaded with realistic relationships for a typical web-app backend (gateway, auth, users, payments, notifications, search, analytics) — and adapt it to your topology. Mark primary adjacency for services with strong runtime coupling, secondary for asynchronous integrations, and undesired for the relationships you want to prevent (Payments ↔ Analytics for PCI scope separation, for example).
The editable PowerPoint export is the headline Pro feature: every cell, marker, and service label becomes a real selectable shape in your slide, so you can recolor cells by service team, swap labels as the system evolves, or copy the matrix to another slide for a before/after comparison. Same workflow applies for design-system component audits where you're tracking UI-level coupling instead of service-level coupling. See the main Adjacency Matrix Diagram tool for the broader set of use cases.
Related variants
Same tool, configured for a related use case.
Frequently asked questions
How is a coupling matrix different from a directed dependency graph?
A directed dependency graph shows which service calls which, with arrows indicating the call direction. A coupling matrix is more compact and bidirectional — each cell encodes the strength of the relationship between two services regardless of which one initiated the call. The matrix forces a deliberate yes/no for every service pair, which catches the unintended couplings that dependency graphs often hide in clutter.
Should I use this for monolith-to-microservices refactoring?
Yes — it's a good fit. Build a matrix of the modules in your monolith, mark each pair's coupling strength as it stands today, then build a target-state matrix showing what the coupling should look like post-refactor. The diff between the two is your refactor roadmap. Export both matrices side-by-side in a single PowerPoint deck for the architecture review.
How do I represent service mesh boundaries in the matrix?
Use the conventional three states for tight coupling (primary), loose coupling (secondary), and prohibited coupling (undesired). For richer encoding — like 'must be in same VPC' or 'must be in same service mesh' — the Phase 2 custom relationship types feature lets Pro users add domain-specific markers with their own symbols and colors.
Can I export the matrix as something I can paste into a Confluence or Notion architecture page?
Yes. The free PNG download embeds cleanly in any wiki page. For higher-fidelity embedding in tools that accept SVG (Notion does via image-block-with-SVG, most internal wikis don't), the Pro SVG export is sharper and scales better. Copy-to-clipboard (also Pro) lets you paste the SVG directly into PowerPoint, Keynote, Figma, or Google Slides as an editable shape group.
Is the data sent to any server?
No. The matrix is built entirely client-side in your browser. Auto-save uses your browser's local storage; the tool never uploads your service names or coupling decisions to our servers. If you want to share a matrix across a team, use the JSON state-file download / upload — it's a small text file you can drop into your repo or wiki.