Skip to main content
Back to Dev generators

Dev

Mock Event Sourcing Payload Generator

Used by developers, writers, and creators worldwide.

The mock event sourcing payload generator produces fully-structured domain event objects for testing event-driven systems built on event sourcing and CQRS patterns. Each payload includes an event ID, aggregate ID, version number, ISO timestamp, event type, and metadata fields like correlation ID and causation ID — everything a real domain event needs without hand-crafting JSON fixtures. Pick from five domains and the generator outputs contextually accurate event vocabularies: ecommerce yields OrderPlaced and CartAbandoned, payments produces PaymentAuthorized and ChargebackRaised, inventory generates StockReserved and ItemRestocked. Set the count to match your scenario, from a single event to a burst batch, and paste the output straight into Kafka, EventStoreDB, or a test fixture file.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Select the domain that matches your system — ecommerce, payments, inventory, user management, or messaging.
  2. Set the event count to the batch size you need, such as 6 for a quick test or 20 for a load scenario.
  3. Click Generate to produce a list of fully-structured domain event JSON payloads.
  4. Copy individual payloads or the full batch and paste into your test fixture, broker producer, or event store client.
  5. Adjust the domain or count and regenerate to create varied event sequences for different test scenarios.

Use Cases

  • Seeding a Kafka topic via kafka-console-producer with realistic payments domain events
  • Populating EventStoreDB or Marten with sample aggregate histories for integration tests
  • Feeding a CQRS projection handler in Jest or pytest to verify read-model update logic
  • Demoing a new event consumer microservice to stakeholders without a live write-side pipeline
  • Bootstrapping Cypress or Postman test fixtures for saga and process manager implementations

Tips

  • Generate 10+ events in the payments domain, then group by aggregate ID to simulate realistic multi-step transaction histories.
  • After generating, standardize the aggregate ID across 5–6 events to test projection handlers that rebuild state from a single stream.
  • Use the causation ID field to manually chain events — set one event's causation ID to the previous event's ID to represent a saga step.
  • For Kafka testing, generate events in ecommerce and inventory domains separately to simulate two upstream topics feeding one consumer.
  • Combine outputs from multiple domain selections to test event routers or dispatchers that must handle heterogeneous event types.
  • When teaching CQRS, generate 3 user-management events and walk through rebuilding the read model manually — the realistic field names make the lesson concrete.

FAQ

can I publish these generated payloads directly to kafka without transforming them

Yes — the payloads are standard JSON and map cleanly to most consumer schemas without custom configuration. Copy the output into kafka-console-producer, paste into Conduktor or Redpanda Console, or deserialize them in a test using your existing Kafka client library.

what are correlation ID and causation ID and why do they matter in event payloads

A correlation ID is a shared identifier attached to every event spawned by the same originating request, even across service boundaries, which lets tools like Jaeger or Zipkin group related spans. A causation ID specifically identifies the parent event or command that directly triggered this one, giving you a precise causal chain for debugging and replay.

what does the version number in each event represent

The version field tracks the optimistic concurrency position of an event within its aggregate stream — event one on an order aggregate is version 1, the tenth event is version 10. Consumers and projections use this to detect gaps, enforce ordering, and prevent concurrency conflicts when appending back to an event store.