Mapping 120,000 devices: how we built a network discovery platform that keeps up

Every large network has the same problem: nobody really knows what's on it. Spreadsheets go stale, CMDBs drift, and the "authoritative" inventory is usually someone's best guess from last quarter. When we set out to build our network discovery platform, we wanted an inventory that stays accurate because it's continuously rebuilt from the network itself.

Today, the platform tracks more than 120,000 devices. Here's how we got there.

Figure 1. The platform architecture, from DNS zone transfers to the versioned API.

DNS as the source of truth, retrieved via zone transfers

The first major decision was where the "truth" should come from. Instead of maintaining yet another device database that people update manually, we anchored the platform in DNS. If a device has a name, it exists in DNS—and DNS is the source that operations teams already maintain, trust, and fix when something breaks.

To pull the devices, we used DNS zone transfers. Instead of scanning IP ranges and hoping to find things, we pull the entire contents of the zones and get a complete list of named devices in one go. From there, the platform adds and verifies each device. The result is a live inventory that reflects reality rather than intent.

Temporal workflows: reliable discovery at scale

Discovering over 120,000 devices isn't a single job. It's hundreds of thousands of small, failure-prone tasks: devices that are slow, unreachable, rebooting, or simply behaving weirdly. We built our orchestration on Temporal, which gave us durable workflows, automatic retries, and clear visibility into what was running and what had failed, without having to write our own retry and scheduling logic.

One schema, defined in Python

Network devices are wildly diverse, so how you model them matters. We defined our internal schema model in Python and made it the contract for everything. Every document written to MongoDB adheres to that schema, keeping the live inventory consistent and predictable even though a switch, a router, and a wireless controller all carry different data.

The model paid off a second time when data needed to be delivered downstream. When another team needed the data in a different shape, we didn't build a parallel data pipeline. We converted from our internal model to the requested one. The internal schema became a single source of truth for the data itself, and other representations were simply translations of it.

New hardware without the headaches

A discovery platform is only as good as its ability to handle the next device type. Vendors, models, and firmware versions expose information differently, and a tool that requires a code change for every new model won't survive a real network.

To solve this, we designed customizable device templates and SNMP collectors. A template defines what to collect and how to parse it for a given class of devices. Onboarding new hardware became mostly a matter of describing it rather than coding it, and because results map back to the same internal schema, new device types slot into the inventory without special handling downstream.

Drawing the map from MAC address tables

Knowing which devices exist is useful. Knowing how they connect changes everything.

Together, we built a topology algorithm that reconstructs the entire network map from MAC address tables. Every switch knows which MAC addresses it has seen on which ports. By correlating that across thousands of devices, the algorithm figures out which devices are connected to which and pieces together the entire picture, from core down to edge, without anyone drawing a diagram by hand.

The payoff is that troubleshooting, impact analysis, and planning become much easier when you can see the actual network instead of the documented one.

Finding the slow parts with Jaeger

At this scale, performance issues hide in plain sight. A step that takes a few hundred milliseconds is unnoticeable on a single device, but painful across 120,000.

We instrumented the code with distributed tracing in Jaeger to see exactly where time was being spent. Instead of guessing, we followed the traces, found the actual bottlenecks, and optimized both the code and the architecture around them.

An API others can build on

Data is only valuable if people can use it. We exposed the platform via FastAPI with a versioned API, allowing other teams to build on top of our data without worrying that a change on our end will break their integrations.

Consumers aren't locked into a one-size-fits-all response either. They can request specialized endpoints with custom schemas and filters, getting exactly the slice of the inventory they need, in the shape they need. Thanks to the internal Python model and its transformations, introducing a new response format is simply a matter of defining the target and mapping to it.

What we learned

• Pick a trusted source of truth and build outward from it. DNS gave us one, and zone transfers gave us a complete, low-overhead way to read it.
• Use durable orchestration for anything touching thousands of unreliable devices.
• Own your schema. An internal model kept storage consistent and turned every alternative representation into a straightforward conversion.
• Make extensibility a feature. Templates and collectors ensured new hardware didn't turn into new engineering projects.
• Measure before optimizing. Tracing showed us where time was actually being spent.
• Treat your API like a product. Versioning and tailored schemas made adoption easy.

The result is a platform that knows what's on the network, how it's connected, and how to share that knowledge in whatever format people need—at a scale of over 120,000 devices and growing.