Dev
Mock Event Sourcing Payload Generator
Testing event-driven systems requires realistic event payloads, but waiting for a live write-side pipeline to produce them is slow and brittle. This generator creates fully-structured domain event objects for five business domains — ecommerce, user-management, payments, inventory, and messaging — each with an event ID, aggregate ID, aggregate type, version number, ISO 8601 timestamp, correlation ID, causation ID, and a generic payload object. Every field is populated with realistic values so you can feed the output directly into a Kafka topic, an EventStoreDB client, or a test fixture without editing first. The domain dropdown controls which event vocabulary is used. Ecommerce produces events like OrderPlaced, CartItemAdded, and OrderRefunded; payments yields PaymentAuthorised, PaymentCaptured, and ChargebackOpened; inventory generates StockAdjusted, LowStockAlerted, and PickingStarted. The count input sets the batch size, from 1 to 30, so you can generate a single event for a unit test or a burst of 30 to stress-test a consumer. A concrete workflow: generate 10 payments events, extract the aggregateId values, group events by the same aggregateId, and feed that stream to a projection handler to verify it rebuilds state correctly. Set causationId on each event to the previous event's eventId to simulate a saga chain.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Select the domain that matches your system — ecommerce, payments, inventory, user management, or messaging.
- Set the event count to the batch size you need, such as 6 for a quick test or 20 for a load scenario.
- Click Generate to produce a list of fully-structured domain event JSON payloads.
- Copy individual payloads or the full batch and paste into your test fixture, broker producer, or event store client.
- 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.
does the payload field match the specific event type in each sample
No — the payload object is generic across all domain events and contains fields like orderId, amount, currency, and status regardless of which event type was drawn. The generator accurately produces the envelope fields (eventId, aggregateId, version, metadata), but the payload body is illustrative rather than event-type-specific.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.