Event-Driven Architecture
A producer/consumer flow through Kafka (Strimzi): an 'orders' topic with a continuous producer and a consumer group. Stage 2 ramps producers to build consumer lag — observe it, then scale consumers (manually or with KEDA's Kafka scaler) to drain it.
What you'll do
- Run a producer/consumer event flow through a Kafka topic
- Create consumer lag by ramping producers past consumer throughput
- Drain the lag by scaling consumers (manually or via KEDA's Kafka lag scaler)
Stages
- 1event-flow
Create the topic and run one producer + one consumer
orders-topicproducer-consumerkafka-metricskafka-lag-dashboard - 2build-lag
Ramp producers to 3x so the single consumer falls behind
ramp-producers
Prerequisites
These are installed into the lab cluster for you — listed so you know what the scenario actually depends on.
Related scenarios
- Autoscaling Under LoadWatch KEDA scale go-api on Prometheus RPS: a spike drives it from 1 to several replicas, then cooldown brings it back. The flagship 'autoscaling actually works' demo, verified under traffic from the load generator.
- Chaos EngineeringFailure injection with Chaos Mesh — pod kills, network delays, CPU/memory stress, partitions. Correlate chaos experiments with application metrics via Grafana dashboard.
- Cost & Capacity: Right-Sizing Over-Provisioned ResourcesDeploy go-api with deliberately over-provisioned CPU and memory requests, observe the inflated cost in OpenCost, then right-size the requests to a realistic baseline. Checks verify that requests were reduced to the target thresholds while go-api stays healthy under traffic. Teaches the observe-measure-reduce loop that keeps platform costs rational.