Event Architecture: Catalog, Consistency Patterns & Operational Excellence

Generic, brand-neutral engineering capability; deep, sourced playbooks live in references/ and knowledge/. [DOC]

Generic, brand-neutral engineering capability; sourced playbooks in references//knowledge/. [DOC]

TL;DR

Event-driven architecture decouples producers from consumers through asynchronous messaging — enabling scalability, resilience, and temporal flexibility. The skill covers event catalog design, broker selection, schema governance, consistency patterns (sagas, CQRS, event sourcing), and the operational practices that keep event systems reliable [EXPLICIT]

When to Use

• Designing event-driven communication between services
• Building an event catalog with taxonomy and schema governance
• Selecting message broker technology (Kafka, RabbitMQ, Pulsar)
• Implementing consistency patterns (sagas, compensating transactions)
• Designing CQRS with event sourcing for complex domains
• Establishing operational practices for event systems (DLQ, monitoring, replay)
• Migrating from synchronous to asynchronous communication

When NOT to Use

• Internal module structure and code organization — use software-architecture
• REST/GraphQL/gRPC API design — use api-architecture
• Data pipeline and ETL/ELT design — use data-engineering
• Infrastructure and compute platform design — use infrastructure-architecture

---

Sub-capabilities (resource map)

Deep, evidence-tagged playbooks — open the one the task needs (ICM Layer 3, on-demand). [INFERENCE]

Procedure

1. Resolve the sub-capability; open the matching references/ playbook. [EXPLICIT]
2. Apply its decision tables; pick the strategy explicitly. [EXPLICIT]
3. Validate against the Quality Criteria and tag every claim. [EXPLICIT]

Quality Criteria

• Sub-capability resolved to one playbook. [INFERENCE]
• Claims evidence-tagged. [EXPLICIT]

Contract

• Aceptación: capability resolved to its reference playbook, applied, validated, evidence-tagged. [EXPLICIT]
• Límites: · Focuses on event-driven architecture patterns, not infrastructure provisioning · Does not design REST/GraphQL APIs · Does not implement data pipelines · Event sourcing adds signi. [EXPLICIT]
• Casos borde: Caso Estrategia de Manejo --- --- Migracion de comunicacion sincrona a event-driven en sistema en produccion Strangler fig pattern. Identificar boundaries de mayor valo. [EXPLICIT]
• Supuestos: · System has multiple services needing asynchronous communication · Team understands distributed systems trade-offs (CAP, eventual consistency) · Infrastructure supports message br. [SUPUESTO]
• Trade-off: Decision Enables Constrains When to Use --- --- --- --- Kafka High throughput, replay, persistence Ops complexity, partition management High-volume, event s. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · assets/ recursos estáticos.