BoardSnap is an iOS app that reads a microservice architecture whiteboard — services, synchronous APIs, asynchronous events, databases, and dependency chains — and produces a structured service topology summary.
Microservice architectures are fundamentally about the relationships between services. A single service is simple to document. The service mesh — twenty services, forty API connections, twelve event topics, and six databases — is where documentation fails. Engineers understand the services they own. Nobody has a clear picture of the whole mesh.
The whiteboard is where the full topology gets visible. When a team debates 'how does Service A know that Service B has completed?' they draw it out. When a performance issue requires tracing a request through six services, they sketch the path. The whiteboard is the only tool in most teams' arsenals that can hold the full service mesh and let people reason about it spatially.
Capturing that whiteboard session is critical. Microservice architectures change constantly — services split, get merged, get deprecated. Without a dated snapshot of 'this is how we understood the architecture on April 26,' there's no record of when a dependency was added or when a service boundary was moved. The whiteboard snap is the version history.
One box per microservice. Write the service name inside the box. Below the name in smaller text, write the technology: 'Auth Service / Node.js,' 'Payments / Go,' 'Notifications / Python.' Keep boxes roughly the same size. Use a grid layout — easier to read dependencies than a free-form blob.
Solid arrows for synchronous API calls. Arrow points from caller to callee. Label each arrow with the API type and endpoint: 'REST POST /charge,' 'gRPC GetUser,' 'GraphQL query.' Bidirectional API relationships get a double-headed arrow.
Dashed arrows for asynchronous event-based communication. Arrow points from publisher to the event topic (draw the topic as a cylinder or hexagon). From the topic, dashed arrows to each subscriber. Label the topic with the event name: 'order.completed,' 'user.registered,' 'payment.failed.'
Each service's database goes next to it, connected by a direct line. Label the database with the technology: 'PostgreSQL,' 'DynamoDB,' 'Redis.' Mark shared databases (multiple services reading/writing the same DB) with a warning marker — these are coupling points that need attention.
Trace the most important user-facing flows through the service mesh. Draw the path with a colored marker and number each hop: 1→2→3→4. A checkout flow through five services, numbered, shows engineering and product where latency accumulates and where failures cascade.
Services being deprecated get a strikethrough or a 'DEPRECATED' label. Services planned for the next quarter get a dashed box outline. These markers turn the diagram from a snapshot into a forward-looking map.
Open BoardSnap. Step well back from the board — a microservice diagram can span a large surface. BoardSnap AI reads service names, technology labels, synchronous vs. asynchronous connection types, topic names, and critical path numbers.
A structured service topology summary: each service listed with its technology, its outbound API connections (to which services, via what protocol and endpoint), its event publications (to which topics), its event subscriptions, and its database. Shared databases are flagged as coupling concerns. Deprecated services are noted. Critical numbered paths are described as step sequences. The output is a service catalog and dependency map — paste it into engineering documentation or an RFC.
Two engineering teams merged and needed a unified architecture map. They spent a morning mapping all services on a large whiteboard — 23 services from two codebases, some redundant, some complementary. BoardSnap produced the full service catalog. The CTO used the output to identify four service pairs that could be merged, reducing the target architecture from 23 to 17 services.
The on-call team drew the dependency graph for their critical checkout flow. Six services, two event topics, one cache. BoardSnap produced the dependency description. The output became the first section of the on-call runbook — when Service D is paged at 2am, the engineer knows which four services it depends on and can check them in order.
The team kept an up-to-date microservice diagram on a permanent whiteboard in the engineering room. Every new engineer got a BoardSnap snap of the current state on their first day. When the architecture changed, they snapped the updated board and added it to the same project. The project became a timestamped history of the architecture's evolution.
Both the line style (solid vs. dashed) and the label are used. If you label API arrows with their protocol (REST, gRPC) and event arrows with the event topic name, the output will correctly classify each connection type even if the line styles are ambiguous. Labels are the primary signal.
For 40+ services, a single snapshot will be dense. Snap a high-level topology overview board, then separate detail boards for each domain cluster (user domain, payment domain, notification domain). All boards go in the same project, and the AI chat can answer cross-board dependency questions.
If the arrows on the board create a visible cycle — A calls B, B calls C, C calls A — BoardSnap will describe that cycle in the output. For large meshes where circular dependencies may not be visually obvious, the AI chat can be asked to identify any cycles described in the board summaries.
Snap the board, ship the action items in ten seconds.