In event driven architecture based on kafka, do you allow "test event" in production topic? If so, how do you effectively manage the downstream impact of the "test event"?
Sort by:
I highly recommend you consider "testing in production" as a promoted practice.
If you're building an event-driven architecture, you can start to conceive of this being your way to do testing, even end-to-end testing, all day, every day if needed.
I was introduced to the power of this by someone that had build out a globally known e-commerce brand.
They would every 5 minutes submit a real order on their site, but use a "testing user" or "testing payment method", these "testing payment methods" would ultimately be automatically cancelled, but all through the normal business mechanisims.
i.e. at the end of the process before inventory was moved and shipments planned, an even listener that could identify these test orders would fire a "cancel order" command message, but it would be processed like a real cancellation.
this let them test their entire purchase and cancel flow all day.
Start to consider ways to do this with your own "testing" indicators - they could be a specific email associated with a user, or a special role. what ever it is, try to leverage your own system recovery or compensating logic to "undo" whatever the test message actually caused earlier.
Sure, allowing "test events" in a production Kafka topic is like sneaking. It's possible, but you better tag it well and train everyone downstream to recognize it. The key is to have clear metadata or flags (like eventType=TEST or isTest=true) baked into the event schema so consumers can easily filter it out or handle it gracefully.