In the Astronomy Shop, what are the load-generator and flagd for, and why does a demo need them?

The load-generator simulates shoppers so there is always traffic to observe; flagd is a feature-flag service that switches in deliberate faults, so there is always something to diagnose.

* The demo as a fire drill for the observability setup itself. *

An observability tool looking at an idle, healthy system has nothing to show. The demo therefore brings its own traffic and its own trouble:

• The load-generator (built on the Python load-testing tool Locust) runs scripted user journeys: browse products, add to cart, check out. It is why the dependency graph shows calls even when nobody is clicking.
• flagd is an OpenFeature feature-flag daemon. Services ask it at runtime whether a flag is on, and flags in the demo inject failure scenarios: make the payment service fail, make the product catalogue return errors for one product, slow down image loading, overload the Kafka queue, and so on.

This mirrors a real practice. Turning a fault on deliberately and checking that dashboards, alerts and traces reveal it is a small form of chaos engineering: it tests the observability setup itself, before a real incident has to.

Go deeper:

• OpenTelemetry Demo — Feature flags — the list of fault-injection scenarios and how to toggle them.
• flagd — the OpenFeature flag daemon the demo uses for fault injection.
• Locust — the Python load-testing framework behind the load-generator.
• Chaos engineering — Wikipedia — deliberately injecting failure to test a system's resilience.