In a traditional and simple scenario, your app setup would have a box for your web server, a box for your api, a box for your database. Each would have a static IP addresses so you know how things would be connected.
Life in a cloud is different. Because it is a cloud we don't really have static IP addresses, instead they are dynamically assigned. Things could fail, increased usage means new instances pop up, decreased usage could mean removing instances. The only constant is change.
Therefore, a service should have a way of discovering dependencies, wait for dependencies to become available, and not fail if a dependency fails or disappears.
So how do we keep a tally of what is where? Discovery mechanisms - Consul.io or Nginx plus for example. The solution is still a client-server architecture - so we could solve it either client or server side.
Client side discovery pattern
It doesn't really seem to be 'client side' tbh, it's more like a middleman. For example, we need a list of all these services to be available, a database, a 'registry service'. The client queries this service registry, gets a list of network locations, uses some algorithm for load balancing to select which service to use.
When a service instance starts up it registers itself with the service registry, and also when it terminates. The registry itself uses a heartbeat mechanism to detect services that are up, ones that aren't are removed.
Server side discovery pattern
You still have a service registry in this pattern, but the difference is it is behind a load balancer (Squid for example, or Amazon's ELB). The load balancer queries the registry, gets the network address, and then uses that service.
Tools
There are lots of tools out there that solve the above. Tools like Rawdns, Meso (orchestration tool), Consul.