Design how your systems connect.

A line on an architecture diagram hides several decisions. Who can reach the service, which path traffic takes, how its name resolves and what happens when that path fails.

Connectivity PlannerFive answers turn a line on the diagram into requirements, owners and tests.5 questionsLive prioritiesNext steps Start planningClose section

Prepare a connectivity brief.

Five questions about one workload connection. Identify the requirements, owners and tests you need before selecting a design. This brief does not verify your network or choose a provider for you.

  1. Question 1 of 5 · Endpoints

    Where must this connection run?

    Choose one connection to assess. Record the actual source and destination names in the brief you take into design.

    Choose one No answer selected

  2. Question 2 of 5 · Access

    Who needs to reach the destination?

    Decide reachability separately from identity and encryption. A private IP does not grant permission to use a service.

    Choose one No answer selected

  3. Question 3 of 5 · Performance

    Have you measured the traffic requirements?

    Include peak throughput, latency, packet loss tolerance, transaction behaviour and expected growth.

    Choose one No answer selected

  4. Question 4 of 5 · Continuity

    What should happen if the primary connection fails?

    A fallback must have working DNS, routing and security rules as well as enough capacity.

    Choose one No answer selected

  5. Question 5 of 5 · Operation

    Are DNS, routing and incident responsibilities assigned?

    Include both ends and any carrier. Someone must own changes, monitoring and the recovery procedure.

    Choose one No answer selected
Four checks behind every connectionFollow the cargo through access, routes, name resolution and a surviving path.AccessRoutingDNSContinuity ExploreClose section

Four checks behind every connection.

Follow the cargo from entrance to delivery. Check access, routes, addresses and what happens when a path fails.

Figure 01 Public & private access
A harbour entrance and a cargo permit are different checks A boom closes the public harbour entrance and an outside yacht stops. At the private quay a cargo permit is rejected, then an approved consignment is lifted into the warehouse. The harbour log records unreachable, denied and allowed. N HARBOUR ACCESS / CARGO PERMITS WAREHOUSE Public entrance Private quay → permit check HARBOUR LOG Outside yachtInvalid permitValid permit Entrance open · cargo still needs permission UNREACHABLE DENIED × ALLOWED ✓

A private entrance still needs an access check.

A private endpoint is a private network entrance, not proof of permission. Like a private quay checking cargo permits, the application must still check who may use it.

Ask about your workload

Which clients need access, over which networks—and how will you test public restrictions, private DNS and application permissions?

Details & limits of the example

A boom shuts the public harbour entrance. At the private quay, an invalid cargo permit is rejected while an approved consignment reaches the warehouse. The entrance represents network reachability; the permit represents permission to use the application.

A private endpoint does not necessarily disable public access; explicitly restrict it when required. Private connectivity does not replace authentication, authorization or appropriate encryption.

Figure 02 Routing
Choose the customs quay, then inspect cargo and the return manifest The direct loading route bypasses customs. On the inspected route a consignment moves through customs to the ship. Its return manifest passes customs on the way back. Two stamps record the outward and return checks, representing request and reply inspection. CUSTOMS QUAY / OUTWARD & RETURN Direct loading · bypasses customs CUSTOMS Cargo = requestReturn manifest = reply Cargo inspected Reply inspected A customs house cannot inspect a bypassing load. Follow the consignment, then its return manifest…1 exchange completed · both directions inspected The chosen route and customs rules allow this exchange.

A firewall only checks traffic that passes through it.

A firewall sees only traffic routed through it. Like sending cargo through customs, inspection needs the intended path, a working return route and rules that allow the exchange.

Ask about your workload

Which traffic needs inspection, and do the effective routes and firewall rules enforce that path in both directions?

Details & limits of the example

A direct loading route bypasses the customs house. Send the consignment through customs instead, then follow its return manifest back through the same check. Cargo represents a request; the return manifest represents its reply. The stamps show which traffic was inspected.

A route makes a path possible. It does not itself grant access or guarantee delivery.

Figure 03 DNS
Ask harbour radio for the berth, then sail to it The captain has an old berth assignment. A radio question reaches the harbour directory. Its answer, berth 4, updates the captain’s note. The yacht then sails directly to berth 4 rather than through the radio office. This represents a DNS answer followed by a separate connection. N HARBOUR RADIO / FIND THE BERTH DirectoryBERTH 4 Old berth · 9Assigned · 4 B 4 CAPTAIN’S BERTH NOTE Berth 9 · 10.20.0.9 Berth 4 · 10.20.0.4 orders.example The captain still has an old berth assignment. Ask by radio → receive berth → sail to it…Fresh berth assignment → arrival at the right quay The directory gives directions; it does not carry the cargo.

Find the address first. Then make the connection.

DNS finds an address, like harbour radio finding a berth. The client then makes the connection; its answer depends on resolver configuration and cached records.

Ask about your workload

What address does each client actually resolve, and can it connect there after a record or network change?

Details & limits of the example

The captain radios the harbour directory for the current berth. The reply updates the captain’s old note, then the yacht sails directly to that quay. The directory represents DNS, the berth represents an address, and the voyage represents the application connection. The new berth is reachable in this example.

Changing DNS is not an instant global traffic switch. Test resolution and connectivity separately.

Figure 04 Redundant connections
A blocked shipping channel interrupts arrivals before a separate passage restores them A vessel stops outside a closed channel. Two scheduled arrivals are missed while the alternate passage is selected. A following delivery sails around the other side of the headland and reaches the quay. The harbour log keeps the missed arrivals visible after recovery. Timings and capacity are illustrative. N TWO PASSAGES / ONE HARBOUR LOG Headland DELIVERY QUAY Inner channelOuter passage · outside the closure CLOSED HARBOUR ARRIVALS Earlier → later · scheduled arrivals Delivering normally Delivery interrupted Delivery resumed A gap remains in the record.

A backup should restore delivery, not just add a line.

A second route helps only if it survives the failure and carries the workload. An outer shipping channel can restore deliveries, but it cannot undo missed arrivals.

Ask about your workload

Which failures must the backup path survive, how much traffic must it carry, and how will you test the interruption and return to normal?

Details & limits of the example

A closure blocks the inner shipping channel. A waiting vessel cannot get through, and scheduled arrivals are missed. A following delivery uses the prepared outer passage instead. The harbour log keeps the missed arrivals visible: a backup restores delivery but does not erase the interruption.

A second connection is not proof of independent failure domains or enough recovery capacity.

Network design in practiceSelected articles and primary sources for the decisions that need a closer look.Practical articlesSource documents Browse notesClose section

Read the detail behind the decision.

These two existing articles were revised for this guide: choosing hybrid connections and validating the routes behind a topology.