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.