service-connectivity
Service Connectivity
Every call one service makes to another is a bet that the other side is up, fast, and honest about its identity. Distributed systems fail at the seams between services far more often than inside any single one — a slow dependency without a timeout, a retry storm without backoff, or a connection that was never actually authenticated all turn a local problem into a cascading one.
Design connectivity assuming the other side will eventually be slow, wrong, or absent — because over enough time, it will be. A call without a timeout is a promise to wait forever, and nothing downstream should ever make that promise.
1. Make service discovery answer "is this instance actually healthy," not just "does it exist"
Discovery mechanisms (DNS-based, a registry, or a mesh control plane) that only track which instances exist — without incorporating readiness — will happily hand out an address for an instance that's up but not ready to serve. Discovery and health need to be the same signal, or a caller ends up needing its own separate health check on top, which most callers skip.