Skip to content
Back to skills

Event Driven Messaging

ASecurity

Use when implementing Kafka, RabbitMQ, Pulsar, or JMS producers and consumers in Spring Boot 3. Covers event contracts, idempotency, retries, dead-letter handling, ordering, and outbox delivery.

  • 272 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 1, 2026
ai-agentsgojavaspringtestingapidatabase

Works with

  • api

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 1, 2026

npx -y skills add rrezartprebreza/spring-boot-skills --skill event-driven-messaging --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Event Driven Messaging?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Event Driven Messaging
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/rrezartprebreza-event-driven-messaging/badge)](https://www.skillsdirectory.com/skills/rrezartprebreza-event-driven-messaging)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: event-driven-messaging
description: >
  Use when implementing Kafka, RabbitMQ, Pulsar, or JMS producers and consumers in Spring Boot 3.
  Covers event contracts, idempotency, retries, dead-letter handling, ordering, and outbox delivery.
---

# Event-Driven Messaging

Design for at-least-once delivery unless the complete system proves stronger semantics.

## Event contract

- Use an immutable event envelope with `eventId`, `eventType`, `occurredAt`, `schemaVersion`, and payload.
- Treat published schemas as APIs. Add fields compatibly and never silently change meaning.
- Put correlation and causation IDs in headers or the envelope.
- Do not publish JPA entities or framework-specific serialization shapes.

## Producer rules

- Publish only after the originating state change is durable.
- Use a transactional outbox when database state and broker publication must agree.
- Use deterministic partition keys when per-aggregate ordering matters.
- Configure delivery timeout and acknowledgements explicitly.

## Consumer rules

- Make handlers idempotent with a durable processed-event record or naturally idempotent write.
- Keep the transaction boundary around the state change and idempotency marker.
- Classify transient and permanent failures before configuring retries.
- Bound retries with backoff, then route poison messages to a dead-letter destination.
- Preserve the original event, failure reason, and attempt count for replay.

## Testing

- Test serialization compatibility and handler idempotency.
- Use Testcontainers for broker integration tests.
- Test duplicate, reordered, delayed, and poison messages.

## Examples

- See `examples/good-consumer.java` and `examples/bad-consumer.java`.

## Gotchas

- Agent assumes exactly-once delivery because the broker supports transactions - end-to-end side effects still need idempotency.
- Agent retries validation failures forever - dead-letter permanent failures promptly.
- Agent publishes inside a database transaction without an outbox - a crash can split state and event delivery.
- Agent uses a random partition key - ordering for one aggregate is then lost.
- Agent deserializes directly into a JPA entity - use a versioned event contract.

Files in this skill

  • SKILL.md2.2 KB
  • agents/openai.yaml207 B
  • examples/bad-consumer.java162 B
  • examples/good-consumer.java1.2 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.