Event-Driven Architecture Working Skill

What this skill is for

This skill helps you identify which business facts should become events, confirm the authoritative source, define the event contract and schema, choose delivery semantics, design failure handling, and maintain an event catalog that consumers can trust.

When to use this skill

• You need to decouple a source system from multiple downstream consumers.
• A polling integration is causing performance issues on the source system.
• You are implementing the output of an event storming workshop.
• A new downstream system needs to react to state changes in SAP or another platform.
• Consumers are receiving duplicate or out-of-order events.
• An event was added without schema governance and is now breaking consumers.

Real work situations

Situation 1: Order status changes trigger four downstream systems

When an order is confirmed in SAP S/4, the warehouse system, billing system, customer notification service, and analytics platform all need to react. Point-to-point API calls create tight coupling and retry complexity. Events are proposed but no one owns the event definition.

Situation 2: Polling integration causing SAP performance issues

A logistics platform polls SAP every five minutes for delivery status updates. During peak periods, the polling volume impacts SAP application server performance. The team wants to replace polling with events but does not know how to guarantee delivery or handle failures.

Situation 3: Duplicate events during retries

A consumer receives order confirmation events multiple times because the producer retries on timeout. The consumer processes each duplicate as a new order, creating duplicate shipments. There is no idempotency key or deduplication logic.

Inputs required

• Business process map showing state changes and triggers.
• List of current and potential consumers with their data needs.
• Existing event catalog (if any).
• SLA requirements: delivery latency, ordering, durability.
• Retry and error handling policies from the organization.
• Middleware or broker capabilities (topics, partitions, retention, schema registry).
• SAP event enablement status (SAP Event Mesh, CDC, custom outbound).

Questions to ask

• What business fact occurred, and who is the authoritative source?
• How many consumers need to know about this fact today? How many in two years?
• What happens if the event is lost? What happens if it is duplicated?
• Does the consumer need strict ordering, or can events be processed out of order?
• What is the maximum acceptable delay between the business fact and consumer receipt?
• How will schema changes be communicated and versioned?
• What is the retention policy for this event, and who decides it?
• How will a consumer prove it is compatible before subscribing?

Working method

1. Identify the business event. Name it after the business fact, not the technical trigger. Example: OrderConfirmed, not SAPTableUpdated.
2. Confirm the authoritative source. Only one system publishes this event. Document why it is authoritative.
3. Define the event contract. Specify event name, schema, version, payload example, and metadata fields (timestamp, correlation ID, source).
4. List consumers and their needs. For each consumer, document what fields they use, their latency requirement, and their ordering requirement.
5. Choose broker and topic strategy. Decide topic naming, partitioning key (if ordering matters), and retention. Record in an ADR.
6. Define delivery semantics. Choose at-least-once, at-most-once, or exactly-once. Document the trade-off and implementation.
7. Design failure handling. Define retry policy, dead letter criteria, and escalation path. Link to Integration Error Handling skill.
8. Add to event catalog. Register the event, schema, owner, consumers, and SLA in the central event catalog.
9. Validate with consumer test. Have a consumer subscribe using the contract. Inject failures and verify retry, ordering, and idempotency behavior.

Decision rules

• If more than three consumers need the same business fact, use an event instead of API polling.
• If strict ordering matters, use a partition key and ordered delivery; otherwise, allow parallel processing.
• If exactly-once processing is required, implement idempotency in the consumer; do not rely on broker guarantees alone.
• If event loss is unacceptable, use a persistent queue with acknowledgment and retry.
• If the consumer is external or untrusted, enforce schema validation at the consumer edge.
• If no event catalog exists, create one before adding new events.
• If the event payload exceeds 100 KB, evaluate whether a reference plus lookup pattern is better than a fat event.
• If SAP is the source, verify whether SAP Event Mesh, CDC, or custom outbound is the right emission mechanism.

Deliverables

• Event Contract — Name, schema, version, example, metadata. See template below.
• Event Catalog Entry — Owner, consumers, SLA, broker, topic.
• Consumer Compatibility Matrix — Which consumers use which fields and versions.
• Architecture Decision Record — Broker choice, delivery semantics, partitioning. Link to ADR template.

Templates

Event Contract Brief

---
artifact: Event Contract Brief
id: EVT-001
status: draft | reviewed | approved
---

## Event name


## Source system


## Schema version


## Payload schema
| Field | Type | Required | Description | Example |
|-------|------|----------|-------------|---------|
| orderId | string | yes | Unique order identifier | ORD-2026-0042 |
| confirmedAt | ISO-8601 | yes | Timestamp of confirmation | 2026-06-09T14:30:00Z |
| customerId | string | yes | Customer reference | C-8821 |
| totalAmount | decimal | no | Confirmed total | 1250.00 |

## Metadata
| Field | Description | Example |
|-------|-------------|---------|
| eventId | Unique event identifier for idempotency | evt-uuid |
| correlationId | Trace identifier across services | corr-uuid |
| source | System that emitted the event | sap-s4-prod |
| emittedAt | Event emission timestamp | 2026-06-09T14:30:01Z |

## Example payload
```json
{
  "orderId": "ORD-2026-0042",
  "confirmedAt": "2026-06-09T14:30:00Z",
  "customerId": "C-8821",
  "totalAmount": 1250.00
}
```

## Delivery semantics



## Ordering requirement


## Consumer list
| Consumer | Fields used | Latency req | Ordering req | Contact |
|----------|-------------|-------------|--------------|---------|
| Warehouse | orderId, confirmedAt | < 30s | No | Team A |
| Billing | orderId, totalAmount | < 5 min | No | Team B |

## Topic / queue


## Owner


## SLA

Quality checklist

• Event has a unique business-fact name, not a technical trigger name.
• Schema is versioned and includes metadata (eventId, correlationId, source, emittedAt).
• Authoritative source system is identified and documented.
• Consumer list is complete with latency and ordering requirements.
• Delivery semantics are defined and implemented.
• Idempotency mechanism is documented.
• Failure path (retry, dead letter, escalation) is documented.
• Event is registered in the event catalog.

Common mistakes

• Mistake: Events without schema governance. Consequence: Producers change fields silently, breaking consumers.
• Mistake: Missing dead letter handling. Consequence: Failed events accumulate in queues, causing backpressure or data loss.
• Mistake: Assuming ordered delivery without explicit configuration. Consequence: Consumers process events out of order and produce incorrect state.
• Mistake: No consumer onboarding process. Consequence: New consumers subscribe to production topics without compatibility checks.
• Mistake: Fat events with entire entity state. Consequence: Payload bloat, serialization cost, and leakage of fields consumers should not see.

Agent instructions

• Gather context first: Collect the business process map, consumer list, existing event catalog, and broker capabilities before designing events.
• Name events by business fact: Do not use table names or technical triggers as event names.
• Define contract before implementation: Produce an Event Contract Brief and get consumer sign-off before coding.
• Ensure idempotency: Always include eventId and document the consumer deduplication strategy.
• Avoid generic language: Do not write "events provide loose coupling." Write "Use an event when three consumers need the same OrderConfirmed fact."
• Link to Atlas diagnostics: For SAP event emission, reference SAP Event-Driven Architecture and CDC for mechanism selection.

Related skills

• API Integration — When events are not the right pattern.
• Integration Observability — Monitor event flows and consumer lag.
• Integration Error Handling — Design retry and dead letter behavior.
• Data Mesh — Events as output ports for domain data products.

Related Atlas pages

• Event-Driven Architecture — Conceptual foundation.
• SAP Event-Driven Architecture — SAP-specific mechanisms.
• Event Contracts — Contract design principles.
• Event Catalog — Governance and discovery.
• Idempotency — Exactly-once processing.
• Dead Letter Queue — Failure handling.

Verification status and limitations

This skill is a public working interpretation of event-driven architecture practice. It is not official SAP, Confluent, or vendor documentation. SAP-specific guidance references SAP Event Mesh and CDC patterns available in recent S/4HANA releases but may not apply to all landscapes. Always verify broker capabilities and SAP release notes before committing to an event strategy.