programmable-service-topology

# Topic

> Programmable service topology

This is either really out there or kinda cool :see_no_evil: :rocket:
(or everybody is doing it over my head)

Ok, so... Currently we "hardcode" our service topology into our services. We might have service discovery and distribution, but we still tell service X it needs to listen to service Y, query service A and B, push to service Z and log to W. This is also a kind of state. Even with abstract transport and message passing, the topology (how the arrange the services) is fixed. To change it we need to modify our services and redeploy.

What if we move the topology to a new layer. All services exist in isolation, reporting their capabilities, and it's not until we apply a topology that they connect to one-another and start processing.

I see interesting benefits;
- Hot/live composability
- Short lived processing pipes
- Efficient processing pipes
- Easier to experiment
- Automation
- Apply learning algorithms

Am I totally wearing my **_not science, just mad**_ hat :tophat: ??
Or is it an interesting topic to discuss further? What are the tradeoffs? How would we go about it?

The issue names no files, tests, or entry points and presents a discussion about moving service topology into a separate layer. Start by reviewing the proposed benefits and tradeoffs in the issue; it does not define an implementation target or criteria for done.

Written by the indexing model from the issue text.