Event driven architect
Skill ulpi-io/plugin-marketplace/plugins/404kidwiz/skills/event-driven-architect
Expert in designing asynchronous, decoupled systems using Event-Driven Architecture (EDA). Specializes in AsyncAPI, Event Mesh, and CloudEvents standards. Use when designing event-driven systems, implementing message queues, or building asynchronous microservices.From its SKILL.md
npx -y skills add ulpi-io/plugin-marketplace --skill event-driven-architectAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.2 KB, 634 tokens by cl100k_base, as published. Nobody here has run it
Event-Driven Architect
Purpose
Provides expertise in designing and implementing event-driven architectures. Covers message brokers, event sourcing, CQRS, and standards like CloudEvents and AsyncAPI for building scalable, decoupled systems.
When to Use
- Designing event-driven architectures
- Implementing message queues and brokers
- Building event sourcing systems
- Implementing CQRS patterns
- Creating AsyncAPI specifications
- Designing event mesh topologies
- Building asynchronous microservices
Quick Start
Invoke this skill when:
- Designing event-driven architectures
- Implementing message queues and brokers
- Building event sourcing systems
- Implementing CQRS patterns
- Creating AsyncAPI specifications
Do NOT invoke when:
- Building synchronous REST APIs (use api-designer)
- Setting up Kafka infrastructure (use data-engineer)
- Building workflow orchestration (use workflow-orchestrator)
- Designing GraphQL APIs (use graphql-architect)
Decision Framework
Message Broker Selection:
├── High throughput, streaming → Kafka
├── Flexible routing → RabbitMQ
├── Cloud-native, serverless → EventBridge, Pub/Sub
├── Simple queuing → SQS, Redis Streams
└── Enterprise integration → Azure Service Bus
Pattern Selection:
├── Audit/replay needed → Event Sourcing
├── Read/write separation → CQRS
├── Simple async → Pub/Sub
├── Guaranteed delivery → Transactional outbox
└── Complex routing → Message router
Core Workflows
1. Event-Driven System Design
- Identify domain events
- Define event schemas (CloudEvents)
- Choose message broker
- Design topic/queue structure
- Define consumer groups
- Plan dead letter handling
- Document with AsyncAPI
2. Event Sourcing Implementation
- Define aggregate boundaries
- Design event types
- Implement event store
- Build projection handlers
- Create read models
- Handle schema evolution
- Plan snapshot strategy
3. AsyncAPI Specification
- Define servers and protocols
- Describe channels (topics/queues)
- Define message schemas
- Document operations (pub/sub)
- Add security schemes
- Generate documentation
- Enable code generation
Best Practices
- Use CloudEvents format for interoperability
- Design idempotent consumers
- Implement dead letter queues
- Version event schemas carefully
- Monitor consumer lag
- Plan for at-least-once delivery
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Synchronous over async | Defeats purpose | Use proper patterns |
| No idempotency | Duplicate processing | Design idempotent handlers |
| Ignoring order | Data consistency issues | Partition by key if needed |
| Huge events | Network overhead | Small events, fetch details |
| No schema evolution | Breaking changes | Versioning strategy |
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.