# Event Driven

> Structure systems around asynchronous, event-based communication to decouple producers and consumers for improved scalability and resilience. Use when building loosely coupled systems with asynchronous message-based communication.

- Skill: `majiayu000/event-driven` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/event-driven`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/event-driven/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/event-driven

---


# The Event-Driven Architecture Paradigm

## When to Employ This Paradigm
- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.
- When multiple, distinct subsystems must react to the same business or domain events.
- When system extensibility is a high priority, allowing new components to be added without modifying existing services.

## Adoption Steps
1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.
2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).
3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.
4. **Plan for Failure Handling**: Implement robust mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.
5. **Instrument for Observability**: Implement comprehensive monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.

## Key Deliverables
- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).
- A centralized schema repository with automated CI validation and consumer-driven contract tests.
- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.

## Risks & Mitigations
- **Hidden Coupling through Events**:
  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.
- **Operational Complexity and "Noise"**:
  - **Mitigation**: Without strong observability, diagnosing failed or "stuck" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.
- **"Event Storming" Analysis Paralysis**:
  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.

*Event Driven v1.1 - Enhanced*

## 🔄 Workflow

> **Kaynak:** [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/) & [AWS Event-Driven Guide](https://aws.amazon.com/event-driven-architecture/)

### Aşama 1: Event Design
- [ ] **Schema**: Event payload'unu (JSON) tanımla ve versiyonla (`v1`).
- [ ] **Granularity**: "OrderCreated" (Fat) vs "OrderReference" (Thin) kararını ver.
- [ ] **Idempotency**: Her event'e unique `event_id` ekle.

### Aşama 2: Architecture Setup
- [ ] **Producer**: Event fırlatma noktasını belirle (Transaction sonrası?).
- [ ] **Broker**: Kafka/RabbitMQ/SQS seçimini load/latency ihtiyacına göre yap.
- [ ] **Consumer**: Hata durumunda (DLQ) retry stratejisini kur.

### Aşama 3: Monitoring
- [ ] **Tracing**: OpenTelemetry ile request zincirini (Producer -> Broker -> Consumer) izle.
- [ ] **Lag**: Consumer lag süresini monitör et (Alarm kur).

### Kontrol Noktaları
| Aşama | Doğrulama |
|-------|-----------|
| 1 | Event schema değişikliği geriye dönük uyumlu mu? |
| 2 | Aynı event iki kere gelirse sistem bozuluyor mu? |
| 3 | Sistem çöküp kalktığında kayıp mesaj var mı? |