excalidash-microservices-topology

Generates and validates microservices topology diagrams with gateway, per-service datastores, and async event bus.

2|Updated Jun 17, 2026
One-click install
npx skills add https://github.com/gabedsam01/excalidash-v2 --skill excalidash-microservices-topology-gabedsam01
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: excalidash-microservices-topology
Source: https://github.com/gabedsam01/excalidash-v2/tree/main/skills/excalidash/excalidash-microservices-topology
Command: npx skills add https://github.com/gabedsam01/excalidash-v2 --skill excalidash-microservices-topology-gabedsam01

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Drawing an accurate microservices architecture diagram by hand is error-prone: shared databases sneak in, sync and async edges get mixed up, and arrows cross labels. This Skill produces a correct microservices topology diagram in Excalidraw — API gateway on top, a row of independent services each owning exactly one datastore, and a queue/event bus for asynchronous traffic — then lints, scores, and validates it against architecture rules. ## Core Features & Use Cases - Topology generation: Creates the full layout (gateway, services row, per-service datastores, bounded-service frames, event bus, sync/async legend) via a dedicated architecture pattern, a template, a prompt structure, or by reverse-engineering a repository's deployables, DB configs, and broker usage. - Architecture validation: Enforces database-per-service ownership, a single gateway front door, solid edges for synchronous HTTP/gRPC calls, and dashed edges for queue/event messages, with a mandatory legend keying both. - Quality loop: Runs lint, score, repair, and polish cycles until the drawing scores at least 95 with zero hard blockers, then saves, versions, and exports it. - Use Case: Ask to diagram an order platform where a Kong gateway fronts OrderService, PaymentService, and InventoryService, each with its own Postgres database, communicating over RabbitMQ — the result is a validated topology with sync/async edges clearly distinguished. ## Quick Start Ask the AI to draw a microservices topology for your system, naming the API gateway, the services, each service's own database, and the queue or event bus used for asynchronous messages.

Frequently Asked Questions about excalidash-microservices-topology

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I draw a microservices architecture diagram with an API gateway?

Describe your system naming the gateway, the services, each service's own database, and the message broker. The skill generates the topology with the gateway on top, services in a row, per-service datastores below each one, and a queue or event bus for async traffic.

How to show synchronous vs asynchronous calls in an architecture diagram?

Synchronous HTTP or gRPC request/response edges are drawn as solid arrows, while queue and event-bus messages are drawn as dashed arrows. A legend block keys both styles so readers can distinguish the two communication types.

Can I generate a microservices diagram from an existing repository?

Yes. The create_from_repo_analysis path derives services from deployable units like Dockerfiles and Kubernetes manifests, datastores from per-service database configs and migrations, and async integrations from broker usage such as Kafka, RabbitMQ, or SQS.

What is database-per-service and why does the diagram enforce it?

Database-per-service means each microservice owns exactly one datastore that no other service touches. The validation step rejects shared databases and cross-service database access because they couple services at the storage layer and break independent deployability.

When should I not use a microservices topology diagram?

Use a different diagram type when the subject is the event flow itself (event-driven), command/query separation (CQRS), domain bounded contexts (DDD), a single container's internals (C4 Container), ports and adapters (hexagonal), or one deployable with internal modules (modular monolith).

Why does my architecture diagram fail validation?

Common failures are a shared database between services, a service reaching into another service's datastore, a service bypassing the gateway, or a solid edge used for an async message. Fix ownership and edge semantics, then re-run lint and scoring until the score reaches 95.