What does standalone Docker Swarm look like with service discovery?

Now that we have a better understanding of the requirements and the reasons behind the usage of service discovery, we can define the (real) flow of a request to a Docker Swarm manager.

Please note that we are still exploring how the old (standalone) Swarm is working:

1. A user sends a request with the desired state to one of the Swarm managers.
2. The Swarm manager gets the cluster information from the service registry, creates a set of tasks, and dispatches them to Swarm workers.
3. Swarm workers translate the tasks into commands and send them to the local Docker Engine which, in turn, runs or stops containers.
4. Swarm workers continuously monitor Docker events and update the service registry.

That way, information about the whole cluster is always up-to-date. The exception is when one of the managers or workers fails. Since managers are monitoring each other, the failure of a manager or a worker is considered a failure of the whole node. After all, without a worker, containers cannot be scheduled on that node:

Now that we established that service discovery is an essential tool for managing a cluster, the natural question is what happened to it in Swarm Mode (Docker 1.12)?