Understanding Your Service Topology¶

What you see

The organized rows and columns of the grid dissolve. Services begin to move - drifting, separating, and regrouping based on their actual connections. The force-directed physics simulation pulls connected services toward each other and pushes unconnected ones apart. After a few seconds, the layout stabilizes into organic clusters.

Services that communicate frequently are now physically close. Isolated services have drifted to the outer edges. The shape of your architecture is visible at a glance - something no flat dashboard can show you.

What you see

From above, your architecture reveals its structure. You might see patterns like:

• A dense cluster on the left - your frontend services and API gateways, tightly interconnected
• A middle band - business logic services (orders, payments, users) connected to both the frontend cluster and the backend
• A cluster on the right - databases and caches, with many incoming connections but few outgoing ones
• A small island floating apart - perhaps a monitoring or logging service with minimal dependencies

The spatial layout encodes information that would take hours to extract from a service catalog.

What you see

The busiest connections in your system are immediately obvious - thick lines with photons streaming along them. You can trace the main request paths through your architecture visually: external traffic enters through the API gateway (thick incoming lines), fans out to business services (medium lines), and converges on databases (thick lines again as multiple services query the same stores). A request that emits a photon but gets none back is a visible failure or timeout.

Quieter connections - background jobs, health checks, async messaging - appear as thin threads with only the occasional photon.

What you see

Tessa produces a structured breakdown of your topology:

• Total services: 22
• Inbound entry points: api-gateway, webhook-receiver
• Most connected service: user-service (11 incoming, 3 outgoing)
• Database services: postgres-primary, redis-cache, elasticsearch
• Isolated services: log-aggregator (no inbound dependencies)

This gives you the data behind what you're seeing visually. The numbers confirm what the spatial layout suggests - and they're useful for sharing with team members who aren't in the 3D environment.

What you see

In the service graph, single points of failure stand out visually. They sit at the center of a starburst of connections - many lines converging on a single node. user-service is a prime example: eleven other services depend on it. If it goes down, all eleven are affected.

When you select it, the dependency lines highlight, and you can count the connections. Hover the node for its tooltip to read its current load and metrics.

What you see

Tessa analyzes load, latency trends, and capacity utilization across your grid. She ranks the most pressured services:

The services under the most pressure are your entry points and shared dependencies - exactly the ones that would cause the widest blast radius if they failed. This is the information you need for capacity planning conversations.

What you see

As you move through the clusters, architectural patterns become tangible:

• Fan-out patterns: A single gateway dispatching to many downstream services - visible as one node with many outgoing lines spreading like a tree
• Fan-in patterns: Multiple services converging on a shared database - visible as many lines funneling into one node
• Service meshes: Tightly interconnected groups where every service talks to every other - visible as dense, web-like connection clusters
• Chains: Sequential dependencies where A calls B calls C - visible as linear paths through the topology

Toggling back to the grid (M) and then returning to the service graph (N) reinforces the contrast: the grid shows you all services equally, while the service graph reveals the actual communication structure.