Network architectures

A fictional library publishes opening hours and lets members renew books online. Visitors need the website; the website needs selected catalog operations; administrators need a separate management path. A useful architecture drawing explains those relationships and the decisions between them.

Trace one request, then mark the assumptions

A browser may reach an edge proxy, a Load balancer, an application, and a data service. A cloud deployment may combine these roles, while another system distributes them across regions. DNS resolution usually happens before the connection; a DNS server is not a mandatory box through which every web request travels.

A load balancer chooses a backend using routing and health policy. A CDN may answer from a cache without contacting the origin for every request. One public address or a familiar response header does not prove the number or identity of systems behind it. Mark a diagram as a proposal or a verified observation and record what remains unknown.

Give each control a specific job

A network firewall enforces traffic policy. Basic rules use addresses, protocols, and ports; some firewalls also inspect application information. A WAF focuses on HTTP behavior. It needs appropriate access to decrypted HTTP to inspect encrypted application content, and it cannot replace the application’s own permission checks.

Detection systems look for suspicious activity using signatures, behavior, or other evidence. Prevention deployments can interrupt traffic or execution. Their effectiveness depends on placement, available telemetry, tuning, and response configuration. Neither the letters IDS nor IPS prove that all harmful behavior will be identified.

Zones need enforced boundaries

A DMZ separates exposed services from other resources. It is one possible design pattern, not a requirement for two physical firewalls or a guarantee that a compromised service cannot reach anything sensitive.

Segmentation means enforcing specific communication rules. A database may still receive necessary requests from an exposed application, so that allowed path needs identity, authorization, and monitoring too. An internal network is not inherently trustworthy, and an internet-facing service may itself hold valuable data.

The diagram says “isolated.” Is that enough?

The library's diagram separates its visitor and administration zones, but its rules permit unrestricted communication between them. The picture documents an intention; the active policy contradicts it. Verify intended connections and denied connections before relying on the boundary.

Review both protection and availability

Ask who owns each rule, where encryption starts and ends, which identities are accepted, and what happens when a control fails. Redundant paths also need consistent policy. Logs should show useful decisions without collecting unnecessary secrets. Continue with network segmentation to turn the drawing into a rule that can be checked.

Read the arrows as dependencies

For the library, start with a visitor asking for opening hours. An edge cache may already hold a public response. A request for the member’s borrowing record must follow a policy suitable for personal information; treating it as a public cached page would change who can receive it. The same website therefore contains flows with different requirements.

Now draw an arrow from the application to the database. Write its purpose beside it: read the catalog, update a renewal, or retrieve one member’s loans. “Database access” is too vague to express these differences. A service identity should have the authority required for its work, and the application must connect a member’s request to the correct permitted operation.

DNS, certificate renewal, monitoring, and backups may be additional dependencies. Their absence from a diagram does not make them unnecessary. Their presence should not justify granting every component broad access to everything. Separate the ordinary request path from maintenance and recovery paths, then identify the policy on each.

A network can be reachable and still refuse an action

Imagine that the library application can reach its data service, but the database rejects its account’s request to change staff records. That is an authorization result after connectivity. In another case, the firewall allows the service but no route reaches it. That is a forwarding problem despite an allow rule. Naming the decision helps the team correct the relevant component.

PredictA backup internet connection restores the website after an outage. Is the architecture review finished?

No. The backup path also needs the intended controls, appropriate logging, and a usable return route. Availability and policy must be checked together; a second path does not automatically inherit the first path’s protections.

Follow a packet’s journey for local delivery and routing. Then use segments, routes, and policy to explain precisely what the network should permit.