Crossing the River Twice: Seven Lessons in Graph Thinking for Microservice Teams
Photo: Diliff, CC BY-SA 3.0, via Wikimedia Commons
The Puzzle That Founded a Science
Eighteenth-century Königsberg had seven bridges joining its riverbanks and islands, and a local pastime: could you walk the city crossing each bridge exactly once? Euler's 1736 answer — no — did more than settle a pub argument. By abstracting landmasses into nodes and bridges into edges, he founded graph theory, the mathematics that now underpins everything from tube maps to service meshes.
His insight was counterintuitive: the layout of the city mattered more than any individual bridge. You cannot reason about connectivity bridge by bridge. You must reason about the whole topology. Substitute 'service' for 'landmass' and 'dependency call' for 'bridge', and you have the central blind spot of microservice adoption.
Seven Bridges, Seven Lessons
1. The Thames crossing counts. London's river is spanned by dozens of bridges, yet planners still obsess over individual crossings rather than network capacity. Likewise, teams audit individual service latency while ignoring that their dependency graph routes everything through one shared gateway. Count the paths, not the parts.
2. Degree predicts fragility. Euler's analysis hinged on counting how many edges touched each node. In your architecture, the node with the highest degree — the service everyone calls — is your single point of failure, whatever its uptime dashboard claims.
3. Some routes are impossible, and that's fine. Euler proved the Königsberg walk could not be done. Not every workflow can be made resilient through cleverness; some dependency chains simply guarantee that one failure cascades. Better to redesign the topology than to add retries to a doomed path.
4. Cycles are where trouble loops. A circuit in your dependency graph — A calls B calls C calls A — is how deadlock and update storms are born. Cycle detection should be a build-time gate, not a post-incident discovery.
5. Bridges cost more than they appear to. Every bridge in Königsberg was expensive to build and maintain. Every synchronous dependency in your mesh carries a similar hidden toll: latency, version coupling, operational on-call surface. Model the cost of each edge before you add it.
6. Draw the map before the outage. Transport planners model river crossings before a bridge closes. Service teams should maintain a live dependency graph — tools exist for this — so that when a node fails, the blast radius is already known rather than being traced in panic at 3 a.m.
7. Abstraction is the actual tool. Euler never visited Königsberg. He solved the problem by discarding irrelevant detail — bridge widths, island sizes — and keeping only structure. Your architecture diagrams should do the same: fewer boxes, honest edges, no vanity services.
Before Your Next Outage
Run one exercise this quarter: export your service dependency graph, compute the degree of every node, and find every cycle. Then ask which edges you would remove if building the system today. Euler's genius was not clever walking routes; it was the discipline of seeing the whole network at once. Your outage postmortems will thank you for adopting it in advance.