Whether you're deciding where to deploy workloads, purchasing colocation space, or evaluating cloud providers, understanding physical datacenter infrastructure is essential. The physical layout determines your fault domains, dictates your availability guarantees, and constrains your cost structure. Power density limits what hardware you can deploy, cooling capacity affects performance consistency, and the network topology impacts your latency and bandwidth options. This knowledge helps you ask the right questions during vendor selection, design for realistic failure scenarios, and troubleshoot outages that trace back to physical infrastructure.

# Racks, Rows, and Pods

When purchasing colocation space or deploying in a cloud provider, you're buying into this hierarchy. Understanding these levels helps you negotiate contracts, plan capacity, and design fault-tolerant systems:

Rack: The fundamental unit. A common full-height rack is 42U, although other standard heights such as 47U are also used; 1U is 1.75 inches (44.45 mm). Servers, switches, and PDUs mount vertically. Each rack has power and network connectivity.

Row: Multiple racks arranged in a line, typically with "hot aisle / cold aisle" layout to manage airflow. Cold air flows from the front (cold aisle), hot air exhausts from the back (hot aisle).

Pod: A group of racks (sometimes called a cluster or zone) sharing power distribution, cooling infrastructure, and often network aggregation. Pods create natural fault domains—power or cooling failure in one pod doesn't affect others. When negotiating colocation contracts, confirm your workloads can be distributed across multiple pods.

# Power Distribution

Power is your most critical constraint—it determines your density limits, operational costs, and availability guarantees. When buying datacenter space, verify the power architecture. A single power failure can take down hundreds of servers if redundancy isn't properly architected. Ask vendors: What's the power capacity per rack? Do you provide dual feeds? What's the UPS runtime?

Redundant Power Feeds (A/B Power)

Dual power feeds (A/B power) can keep a server running after loss of one path when the paths are independent and the surviving path is sized for the full load. A dual-corded server has two power supplies (PSUs), each connected to a different rack PDU; the upstream UPS, utility, and generator topology varies by facility.

Failure scenario: If path A loses its upstream source, UPS A bridges the load until that source returns or its generator accepts the load. If rack PDU A or PSU A fails, PSU B can carry the server only when path B and PSU B are independent and sized for the full load. A dual-corded server still fails if a shared upstream component fails or the surviving path is overloaded.

Multi-AZ design: When workload requirements justify it, distribute production resources across the provider's documented availability-zone boundaries. Placement alone is insufficient: traffic routing, data replication, health detection and failover, capacity in surviving zones, and every critical dependency must continue to work there. Review each service's documented isolation and multi-AZ behavior rather than treating an availability zone as equivalent to a physical pod. (AWS guidance)

# Cooling Systems

Rack density is site- and workload-dependent: a 2025 Uptime Institute survey found the modal average near 9 kW, with 10-30 kW deployments increasing; racks at 30 kW and above are commonly treated as high density, and current AI systems can exceed 100 kW per rack. Without adequate cooling, your workloads don't just fail, they throttle first, creating subtle performance degradation before outright failures. When evaluating datacenter space, ask: What's the cooling capacity per rack? What happens during cooling system failures? Are there redundant cooling units? In extreme cases, datacenters shut down servers to prevent hardware damage—your uptime depends on cooling infrastructure you can't directly control.

Hot Aisle / Cold Aisle Layout

Airflow: Cold air is pumped under a raised floor, flows up through perforated tiles in the cold aisle, gets pulled through servers (front to back), and exhausts hot air into the hot aisle. Hot air is captured and returned to CRAC (Computer Room Air Conditioning) units for cooling.

Why this matters: Improper airflow (e.g., missing blanking panels in racks, blocked cold aisles) causes hot spots. Servers in hot spots throttle performance or shut down, creating mysterious "node failures" that are actually thermal issues.

Real-world outage: On July 19, 2022, extraordinary outside temperatures combined with the simultaneous failure of multiple redundant cooling systems in one building that hosted part of europe-west2-a. Google powered down that part of the zone to protect the infrastructure, terminating the VMs in the building—approximately 35% of the zone's VMs. Cooling impact lasted 4 hours 8 minutes, cloud service restoration took 18 hours 23 minutes, and the longest-tail instance recovery took 35 hours 15 minutes. (Incident report)

What widened the impact: A separate routing change intended to avoid the affected zone was incorrectly configured to avoid all three europe-west2 zones. This made some regional services unable to reach any replica for some storage objects until Google corrected the routing change later that day.

Google's response: Google committed to repairing and re-testing failover automation, developing ways to reduce thermal load progressively, examining recovery procedures and tooling, conducting detailed analysis of the cooling failure, and auditing cooling equipment and standards globally.

Key lesson for users: Redundant facility systems can fail together, so verify provider failure boundaries and recovery procedures. This incident does not show that all zones shared cooling: the direct thermal impact was one building hosting part of one zone. Multi-Region deployment is a separate architecture decision based on availability and consistency requirements, recovery objectives, service dependencies, operational capability, and cost.

# Network: Top of Rack (ToR) vs End of Row (EoR)

Network architecture determines your fault isolation, latency, and bandwidth capacity. When evaluating datacenter providers, ask about their network topology—it affects both your availability and performance profile. Two common approaches for connecting racks to the network:

Top of Rack (ToR) Switches

Pros: In a single-ToR, single-homed design, a ToR switch failure disconnects that rack; dual-ToR and multihomed designs can preserve connectivity. Short in-rack cable runs reduce cable cost and simplify cabling. Preferred for workloads requiring predictable failure domains.

Cons: More switches to manage. If buying your own hardware, higher upfront switch costs (offset by lower cable costs).

End of Row (EoR) Switches

Pros: Fewer switches to manage. Potentially lower initial deployment cost.

Cons: In a single-switch, single-homed design, a switch failure disconnects the attached racks. Longer and denser horizontal cable runs than ToR. If you're buying space in an EoR datacenter, ask how switch redundancy is handled and what the expected impact radius is for switch failures.

Modern approach: ToR dominates modern datacenters due to better fault isolation, especially with leaf-spine topologies (covered in Network Topology). When evaluating providers, confirm they use ToR architecture if your workload requires rack-level fault isolation.

# Fault Domains from Physical Layout

Understanding fault domains is crucial for capacity planning and SLA design. These boundaries determine what can fail together and inform your redundancy strategy:

• Rack-level: ToR switch failure, PDU failure, or power feed issue affects one rack (~40-80 servers)
• Row-level: Cooling failure in a hot aisle can affect an entire row
• Pod-level: Power distribution failure, cooling plant failure, or network aggregation failure affects an entire pod (hundreds to thousands of servers)
• Datacenter-level: Building power loss, natural disaster, or network partition from internet

Design implication: When purchasing datacenter space or deploying to cloud providers, map your availability requirements to fault domains. For 99.99% uptime, deploy across multiple pods. For mission-critical systems (99.999%+), deploy across multiple datacenters or regions. For colocation, ask whether rack and pod placement guarantees are available and which power, cooling, or network components are shared. For cloud, review the provider-documented AZ boundaries and how each service uses them.

# Key Takeaways for Datacenter Users

• Fault domains drive availability design: Physical layout creates hierarchical failure boundaries (rack > row > pod > datacenter). Map your SLA requirements to these domains when purchasing space or deploying workloads.
• Power architecture is non-negotiable: Verify dual power feeds (A/B) with separate UPS systems. Ask about per-rack power capacity—it constrains your hardware density and operational costs.
• Cooling is a hidden SLA dependency: Cooling failures cause both performance degradation (throttling) and hard outages (automated shutdowns). Even redundant systems fail under extreme conditions. Ask about cooling capacity, redundancy, and thermal stress testing.
• Network topology affects blast radius: ToR switches provide better fault isolation than EoR. Confirm the network architecture when evaluating providers—it determines what fails together.
• Availability zones vary by provider: Review documented provider boundaries and service-specific behavior; validate routing, replication, failover, dependencies, and surviving capacity for your workload.
• Real incidents validate your assumptions: Google's 2022 incident combined a facility failure with a separate routing error. Design across zones or Regions according to requirements and verified provider boundaries.