# The map draws itself from the spans

There is no topology to declare. Maple reads parent-child relationships out of the traces you already send, so a new service appears on the map the first time it is called.

## Twelve services, one table

Latency percentiles, error rate and throughput per service, over the range you picked. Sort by p99 and the row that needs you is the top row.

- **topology**: derived from spans
- **nodes**: service · db · cache · external
- **edges**: parent → child
- **per.service**: p50 · p95 · p99 · error% · req/s
- **colour**: 16 hues · service identity

## Reading the neighbourhood

### edges — Edges are real calls

Every line between two nodes is a parent-child span pair that actually happened, carrying its own request rate and error rate. Nothing on the map is declared.

### db.system — Databases and caches too

Client spans become nodes, so Postgres, Redis and every third-party API sit on the map beside your own services with the same latency columns.

### 1-hop / 2-hop — One hop, two hops

Focus a node and the map collapses to what it talks to. A forty-service estate becomes the six services that matter to the question you are asking.

### service.name — Colour by identity

Each service holds one of sixteen hues, and holds it everywhere — the map, the waterfall, the charts. Colour means which service, never how healthy.

### service.version — Deploys on the same axis

A service's detail view marks releases against its latency, so a step change lines up with the version that introduced it instead of a hunch.

## Related

- [Distributed Tracing](https://maple.dev/features/distributed-tracing.md)
- [Kubernetes Monitoring](https://maple.dev/features/kubernetes-monitoring.md)
- [Metrics & Dashboards](https://maple.dev/features/metrics-dashboards.md)
- [Microservices Debugging](https://maple.dev/use-cases/microservices-debugging.md)