16.1 Enterprise GIS Architecture, Server Tiers, Sizing & Capacity Planning

16.1 Enterprise GIS Architecture, Server Tiers, Sizing & Capacity Planning

Core Principle: Designing an enterprise GIS requires balancing user productivity requirements against computational capacity, storage performance, and network throughput. Unlike standard transactional IT applications, geospatial workflows impose asymmetric demands: spatial data transfers involve massive geometric payloads, analytical queries trigger computationally intensive spatial indexing operations, and cartographic rendering taxes both CPU and GPU resources. Mastering capacity planning—grounded in Dave Peters' System Architecture Design methodology—enables geospatial professionals to calculate hardware sizing, network bandwidth, and high-availability topologies that prevent server failure during peak enterprise utilization.

---

1. Enterprise Architecture Framework & The Dave Peters Capacity Planning Methodology

Capacity planning is the proactive engineering process that ensures computing infrastructure can fulfill current operational workloads while scaling to meet future organizational demand. In geospatial systems engineering, the foundational framework for sizing enterprise GIS infrastructure was formulated by Dave Peters in his seminal work, System Design Strategies.

   +-------------------------------------------------------------------------+
   |             THE SYSTEM ARCHITECTURE DESIGN (SAD) LIFECYCLE              |
   +-------------------------------------------------------------------------+
   | 1. User Requirements Analysis: Document workflows, roles, and software  |
   |    profiles across all organizational departments.                      |
   +-------------------------------------------------------------------------+
                                      |
                                      v
   +-------------------------------------------------------------------------+
   | 2. Workflow Characterization: Map workflows into standard service       |
   |    profiles (Simple, Medium, Complex dynamic map/data requests).        |
   +-------------------------------------------------------------------------+
                                      |
                                      v
   +-------------------------------------------------------------------------+
   | 3. Concurrency Modeling: Calculate peak concurrent users from named     |
   |    accounts and quantify transaction arrival rates (TPS).               |
   +-------------------------------------------------------------------------+
                                      |
                                      v
   +-------------------------------------------------------------------------+
   | 4. Infrastructure Sizing: Determine CPU cores (SPECint ratings), RAM,   |
   |    disk IOPS, and network bandwidth needed for peak loads.              |
   +-------------------------------------------------------------------------+
                                      |
                                      v
   +-------------------------------------------------------------------------+
   | 5. Implementation, Validation & Tuning: Deploy architecture, benchmark  |
   |    via synthetic stress tests, and continuously monitor server metrics. |
   +-------------------------------------------------------------------------+

Workflow Characterization & Service Complexity Profiles

Not all GIS interactions consume the same computational resources. A sound capacity plan categorizes user activities into distinct service complexity profiles based on compute time, memory consumption, and data transfer size:

1. Cached Map Services (Static Tiling): Pre-rendered 256x256 or 512x512 pixel raster or vector tiles stored on disk, object storage, or a CDN. Server execution time is negligible ($< 10\text{ ms}$), with resource consumption concentrated almost entirely on network bandwidth and disk I/O.
2. Simple Dynamic Map Services: Real-time rendering of a few vector layers with basic symbology and simple spatial filters. Processing consumes modest CPU time ($0.1$ to $0.3\text{ seconds}$ per transaction).
3. Medium Dynamic / Feature Services: Direct database attribute querying, feature extraction, and interactive vector streaming with moderate geometric complexity. Processing consumes $0.3$ to $0.8\text{ seconds}$ of server CPU time.
4. Complex Spatial Queries & Geoprocessing: Heavy spatial joins, dynamic buffer generation, viewshed analysis, network routing, or enterprise version reconciliation. Processing requires substantial CPU execution ($1.5$ to $10+\text{ seconds}$ per transaction) and significant server memory.

User Roles: Light, Standard, and Heavy

In user requirements analysis, organizations classify personnel into standard archetypes to estimate computational load:

• Light Users (Web Consumers / Field Viewers): Casual consumers navigating public dashboards, utility viewer portals, or field survey collection apps. They generate intermittent requests with long think times ($30$ to $60\text{ seconds}$) between clicks, typically querying cached tiles or simple feature services.
• Standard Users (GIS Analysts / Departmental Staff): Personnel executing spatial queries, thematic mapping, simple geoprocessing, and attribute edits. Think times range from $15$ to $30\text{ seconds}$.
• Heavy Users (Power Analysts / Photogrammetrists / Geodatabase Admins): Advanced users executing complex topological edits, continuous spatial model runs, orthophoto processing, LiDAR classification, or massive batch ETL imports. Think times can drop below $10\text{ seconds}$, or long-running automated batch jobs may saturate computing cores continuously.

---

2. Concurrency Modeling: Peak Concurrency vs. Named Users

A critical failure in enterprise system design is confusing named users (or registered users) with concurrent users:

• Named Users: The total number of individual user accounts registered in the enterprise identity store or license pool (e.g., 2,500 municipal employees).
• Active Users: The subset of named users logged into the enterprise system during a given business day or shift (e.g., 600 users).
• Peak Concurrent Users: The number of users simultaneously interacting with the system during the busiest operational hour of the day, submitting requests that overlap in server memory and CPU queues.

The Concurrency Ratio Rule of Thumb

In standard enterprise IT and GIS capacity planning, peak user concurrency typically ranges from 10% to 20% of the active user base, or 5% to 10% of total named users:

$\text{Peak Concurrent Users} = \text{Active Users} \times \text{Concurrency Ratio} \quad (0.10 \le \text{Ratio} \le 0.20)$

If an emergency operations center has 400 active personnel during a disaster event, designing for a 15% peak concurrency ratio yields:

$\text{Peak Concurrent Users} = 400 \times 0.15 = 60\text{ concurrent users}$

User Productivity, Think Time & Transaction Rates (TPS)

Servers do not process "users"; they process transactions per second (TPS). A concurrent user does not generate a continuous stream of server requests. Between submitting a map pan/zoom or query request and receiving the response, the user pauses to view the map, read attribute tables, or interpret results. This pause is defined as User Think Time ($T_{\text{think}}$).

   <---------------------- USER INTERACTION CYCLE ---------------------->
   +------------------+-----------------------+-------------------------+
   | Request Sent     | Server Processing     | User Think Time         |
   | & Network Transit| (CPU Service Time)    | (User interprets map)   |
   | [ 0.05 sec ]     | [ 0.25 sec ]          | [ 15.0 to 30.0 sec ]    |
   +------------------+-----------------------+-------------------------+

The total cycle time for a single user interaction is:

$T_{\text{cycle}} = T_{\text{service}} + T_{\text{network}} + T_{\text{think}}$

Because $T_{\text{think}}$ ($15$ to $30\text{ s}$) dwarfs $T_{\text{service}}$ and $T_{\text{network}}$ ($0.2$ to $0.5\text{ s}$), the transaction arrival rate generated per concurrent user is approximately $1 / T_{\text{think}}$.

The aggregate enterprise transaction throughput (TPS) at peak load is calculated as:

$\text{Peak TPS} = \frac{N_{\text{concurrent}}}{T_{\text{service}} + T_{\text{network}} + T_{\text{think}}} \approx \frac{N_{\text{concurrent}}}{T_{\text{think}}}$

Example Calculation: If 100 peak concurrent users interact with a web mapping portal with an average think time of 20 seconds, the server must support:

$\text{Peak TPS} = \frac{100}{20\text{ s}} = 5\text{ transactions per second (TPS)}$

---

3. Network Sizing, Bandwidth, and Latency Calculations

Geospatial web transactions carry significantly larger data payloads than standard tabular web applications. While a typical web page request transfers 10 to 50 KB of JSON or HTML, an uncompressed dynamic vector feature service or high-resolution orthophoto request can deliver 500 KB to several megabytes per transaction.

Network Bandwidth Sizing Formula

To prevent network interfaces and switches from saturating during peak usage, required network bandwidth is calculated by multiplying peak transaction rates by average transaction payload size:

$\text{Bandwidth (Bytes/sec)} = \text{Peak TPS} \times \text{Average Payload Size (Bytes)}$

Because network transmission speeds are rated in bits per second (bps), convert bytes to bits using the standard factor of 8 ($1\text{ Byte} = 8\text{ bits}$):

$\text{Required Bandwidth (Mbps)} = \frac{\text{Peak TPS} \times \text{Average Payload Size (KB)} \times 8}{1,000}$

Scenario: A county GIS department projects a peak load of $25\text{ TPS}$ for a mobile tax parcel map. Profiling shows the average JSON feature payload is $150\text{ KB}$:

$\text{Bandwidth (Mbps)} = \frac{25\text{ TPS} \times 150\text{ KB} \times 8}{1,000} = 30\text{ Mbps}$

To accommodate network traffic bursts, packet retransmissions, and protocol overhead, network engineers apply a safety headroom factor of 1.5 to 2.0, requiring a dedicated network pipe of at least $45$ to $60\text{ Mbps}$.

Network Latency vs. Bandwidth: The "Chatty Client" Trap

A critical distinction on the GISP exam is the fundamental difference between bandwidth and latency:

• Bandwidth: The volume of data that can be transmitted across a network connection per unit time (e.g., 100 Mbps, 1 Gbps). It represents the width of the communication pipe.
• Latency: The time required for a data packet to travel from the sender to the receiver and return (Round-Trip Time / RTT, measured in milliseconds, ms). It represents the speed of travel through the pipe.

   +-------------------------------------------------------------------------+
   |                  BANDWIDTH VS LATENCY IN ENTERPRISE GIS                 |
   +-------------------------------------------------------------------------+
   | High Bandwidth + Low Latency (LAN: 1 Gbps, 1 ms RTT):                   |
   |   - Ideal for direct two-tier desktop DBMS connections (ArcGIS Pro/QGIS)|
   |   - Thousands of rapid SQL queries execute in milliseconds.             |
   +-------------------------------------------------------------------------+
   | High Bandwidth + High Latency (WAN/VPN: 1 Gbps, 80 ms RTT):             |
   |   - Catastrophic for direct two-tier desktop DBMS connections.          |
   |   - 500 sequential SQL queries x 80 ms RTT = 40 seconds of blank screen!|
   |   - Adding more bandwidth (e.g. 10 Gbps) DOES NOT solve this latency lag.|
   +-------------------------------------------------------------------------+

Desktop GIS applications (such as ArcGIS Pro or QGIS) opening an enterprise geodatabase table execute hundreds or thousands of sequential, "chatty" SQL queries to validate schemas, populate spatial indexes, and fetch attribute domains. Over a Local Area Network (LAN) with $<2\text{ ms}$ latency, 1,000 sequential queries complete in 2 seconds. Over a Wide Area Network (WAN) or VPN with $60\text{ ms}$ latency, those same 1,000 sequential round trips require:

$1,000 \times 0.060\text{ s} = 60\text{ seconds of application freeze!}$

[!IMPORTANT] The WAN Architecture Rule: Direct two-tier client-to-database GIS connections must never be deployed across high-latency WAN or VPN links. To support remote offices or teleworkers, organizations must deploy either:

1. Three-tier or four-tier web service architectures (where the client requests single, consolidated REST payloads over HTTPS).
2. Virtual Desktop Infrastructure (VDI) (e.g., Citrix, VMware Horizon, Amazon WorkSpaces) located on the same high-speed LAN as the database, streaming only compressed display pixels across the WAN.

---

4. Hardware Sizing: CPU Cores, Memory (RAM), and Storage I/O

CPU Core Sizing & Target Utilization Headroom

CPU sizing in the Dave Peters methodology translates peak transaction rates and service processing times into required physical or virtual CPU cores. The computational workload depends on the service execution time ($T_{\text{service}}$), which is the server CPU processing time consumed per transaction.

$\text{Required CPU Capacity (Cores)} = \frac{\text{Peak TPS} \times T_{\text{service}}}{\text{Target CPU Utilization Rate}}$

In capacity engineering, Target CPU Utilization Rate is intentionally capped at 70% to 80% (0.70 to 0.80). Sizing for 100% CPU utilization causes catastrophic performance degradation due to non-linear queuing theory (the "knee of the curve" in M/M/c queuing models), where request wait times spike exponentially as utilization approaches saturation.

Sizing Example: An enterprise GIS must support a peak rate of $12\text{ TPS}$ for dynamic map rendering, where profiling demonstrates each transaction requires $0.35\text{ seconds}$ of CPU processing time. The organization targets a conservative 70% maximum utilization headroom:

$\text{Required Cores} = \frac{12\text{ TPS} \times 0.35\text{ s}}{0.70} = \frac{4.2}{0.70} = 6.0\text{ Cores}$

The architecture team must provision a server with at least 6 dedicated physical cores (or 8 standard virtual CPU cores) allocated exclusively to the GIS server map service container.

Memory (RAM) Sizing & Process Isolation

Memory sizing for enterprise GIS servers differs fundamentally from standard web servers because GIS server instances are heavy C++ runtime engines (e.g., Esri ArcSOC processes or MapServer CGI instances):

• Service Instance Footprint: Each running instance of a dynamic map or feature service typically consumes between 150 MB and 350 MB of RAM in idle or active execution.
• Process Isolation Models:
  • Dedicated Instances (High Isolation): Each service maintains dedicated operating system processes. Guarantees deterministic performance and isolates crashes, but consumes massive memory ($N_{\text{services}} \times N_{\text{instances}} \times 250\text{ MB}$).
  • Shared Instances (Dynamic Pooling): Multiple low-traffic services share a common pool of worker processes, dramatically reducing idle RAM footprint across hundreds of published layers.
• Database Buffer Pools: The enterprise RDBMS tier (PostgreSQL, Oracle, SQL Server) requires sufficient RAM to cache spatial tables, spatial index nodes (R-Tree/GiST), and query working memory. As a rule of thumb, 50% to 75% of total system RAM on dedicated database hosts should be assigned to the DBMS buffer pool (shared_buffers in PostgreSQL, buffer pool memory in SQL Server).

Storage Tiers & Disk I/O (IOPS)

Storage performance is quantified by throughput (MB/s) and Input/Output Operations Per Second (IOPS). Spatial databases execute intensive random read operations during spatial index traversals and sequential write operations during write-ahead logging (WAL) and version reconciliation.

[!CAUTION] The Database Disk Bottleneck: Placing enterprise geodatabase transaction logs (pg_wal, SQL Server .ldf, or Oracle redo logs) on the same mechanical disk or low-IOPS virtual volume as spatial data tables causes write-lock contention. Transaction-log storage should meet measured latency, durability, and throughput requirements; separating logs from competing I/O can help, but a dedicated NVMe volume is an architectural choice rather than a universal requirement.

---

5. Multi-Tier Enterprise Architectures

Modern enterprise GIS implementations employ tiered architectural patterns to isolate security boundaries, optimize compute scaling, and prevent database saturation.

   +-------------------------------------------------------------------------+
   |                  FOUR-TIER ENTERPRISE GIS ARCHITECTURE                  |
   +-------------------------------------------------------------------------+
   
   TIER 1: CLIENT TIER
     [ Web Browsers ]        [ Mobile Field Apps ]       [ Desktop Pro GIS ]
            |                         |                          |
            +-------------------------+--------------------------+
                                      |
                                      | HTTPS (Port 443)
                                      v
   TIER 2: WEB / REVERSE PROXY TIER (DMZ)
     +-------------------------------------------------------------------+
     | Load Balancer / Reverse Proxy (Web Adaptor / Nginx / AWS ALB)    |
     | - Terminates SSL/TLS (HTTPS)                                      |
     | - Hides internal ports (6080, 6443)                               |
     | - Enforces Web Application Firewall (WAF) filtering               |
     +-------------------------------------------------------------------+
                                      |
                                      | Internal Private Network
                                      v
   TIER 3: GIS APPLICATION SERVER TIER (Cluster)
     +----------------------------------+--------------------------------+
     | GIS Server Node 1                | GIS Server Node 2              |
     | (Map / Feature / Vector Services)| (Dynamic Rendering / Utility)  |
     +----------------------------------+--------------------------------+
     | Geoprocessing Server Node        | Image Server Node (Rasters)    |
     +----------------------------------+--------------------------------+
                                      |
                                      | Dedicated SQL / Low Latency
                                      v
   TIER 4: DATA & STORAGE TIER
     +----------------------------------+--------------------------------+
     | Enterprise Spatial RDBMS         | Clustered Shared Storage       |
     | (PostgreSQL/PostGIS, SQL Server) | (NFS/SMB, Tile Cache, S3/Blob) |
     +----------------------------------+--------------------------------+

Functional Breakdown of Architecture Tiers

1. Tier 1: Presentation / Client Tier: Endpoints that consume spatial services, including desktop GIS, web mapping applications (JavaScript APIs), mobile field apps, and external third-party consumers.
2. Tier 2: Web / Reverse Proxy Tier: Positioned within the enterprise network perimeter or Demilitarized Zone (DMZ). A reverse proxy (such as Esri Web Adaptor, Nginx, HAProxy, or AWS Application Load Balancer):
   • Terminates public SSL/TLS encryption, decrypting incoming traffic.
   • Conceals internal server hostnames and administrative port numbers (e.g., mapping https://maps.city.gov/gis/rest to internal host http://gisapp01:6080/arcgis/rest).
   • Distributes incoming user requests across available application server nodes.
3. Tier 3: GIS Application Server Tier: Clustered servers hosting map services, geocoding services, feature services, and geoprocessing tasks. They execute spatial business logic, draw map layers, and transform raw database records into GeoJSON, PBF vector tiles, or PNG images.
4. Tier 4: Data & Storage Tier: Houses the authoritative geospatial data, including relational spatial databases (PostgreSQL/PostGIS, Oracle Spatial, Microsoft SQL Server), distributed configuration stores, file shares, and cloud object stores (for cached map tiles and raw imagery).

---

6. Load Balancing Mechanics & Algorithms

When user demand exceeds the processing capacity of a single GIS server, multiple server instances are grouped into a cluster behind a load balancer. The load balancer evaluates incoming HTTP/HTTPS traffic and routes requests according to predefined routing algorithms:

• Round-Robin: Requests are distributed sequentially across all healthy server nodes in the pool ($Node_1 \rightarrow Node_2 \rightarrow Node_3 \rightarrow Node_1$). Effective only when all incoming requests impose identical computational loads (e.g., uniform cached tile requests).
• Least Connections: The load balancer routes incoming requests to the server node currently handling the fewest active connections. This is the recommended algorithm for dynamic GIS map and geoprocessing services, because spatial query processing times vary dramatically (from 50 ms to 10 seconds).
• IP Hash: The client's source IP address is hashed to assign the client consistently to a specific backend server. Useful when stateful local caching is required.
• Sticky Sessions (Session Affinity): The load balancer sets a session cookie in the user's browser, forcing all subsequent requests from that user to hit the exact same backend server.

[!WARNING] The Sticky Session Trap in Web GIS: Sticky sessions should be avoided in modern stateless RESTful Web GIS architectures. If 50 users connect during an emergency event and are "stuck" to Server Node A, and Server Node A experiences high load while Server Node B sits idle, sticky sessions defeat the core purpose of horizontal scaling. REST services are intrinsically stateless and should be balanced dynamically using Least Connections.

Health Probes & Circuit Breaking

Load balancers continuously interrogate backend GIS server health by transmitting synthetic HTTP probes to dedicated health-check endpoints (such as https://gisapp01:6443/arcgis/rest/info/healthcheck):

• If a node fails to respond with an HTTP 200 OK within a specified interval (e.g., 5 seconds across 3 consecutive probes), the load balancer flags the node as unhealthy and automatically drains traffic away from it.
• Once the failing server recovers and successfully passes health checks, traffic is restored automatically without administrative downtime.

---

7. Disaster Recovery (DR), RTO & RPO

Business continuity planning for enterprise GIS requires formal operational metrics that dictate disaster recovery infrastructure:

• Recovery Time Objective (RTO): The maximum acceptable elapsed duration between an unscheduled system outage and the complete restoration of GIS services to end users. (Example: An RTO of 2 hours means maps and editing capabilities must be restored within 120 minutes of a hardware catastrophe).
• Recovery Point Objective (RPO): The maximum acceptable age of data loss resulting from a disaster, measured backwards in time from the moment of failure. (Example: An RPO of 15 minutes means that if a catastrophic failure occurs, the organization can tolerate losing at most 15 minutes of newly digitized field edits).

   <========================= TIMELINE OF A DISASTER =========================>
   
   Last Successful                                    Disaster Occurs
   Data Replication                                   (Server Crash / Flood)
   +--------------------------------------------------X
   | <-------------- RPO --------------> |
   |      (Maximum Allowable Data Loss)  |
   
                                                      Disaster Occurs
                                                      X-------------------------+
                                                      | <------- RTO --------> |
                                                      | (Time to Restore Live) |
                                                                               Services Online

Standby Topologies Comparison

Backup Strategies in Enterprise Geodatabases

Meeting aggressive RTO and RPO mandates requires a layered backup strategy:

1. Full Database Backups: Comprehensive image of the entire database taken periodically (e.g., weekly).
2. Differential Backups: Captures all data blocks changed since the last full backup, taken daily to minimize restore times.
3. Transaction Log Backups: Captures the continuous stream of database commit logs (WAL in PostgreSQL, .trn in SQL Server, redo logs in Oracle) every 5 to 15 minutes. Transaction log backups are essential for point-in-time recovery, allowing a geodatabase administrator to restore the spatial database to the exact minute preceding a catastrophic user corruption or system failure.

---

8. Practical Geospatial Scenario: Municipal Sizing for an Emergency Public Outage Dashboard

Scenario Context

A metropolitan electric and water utility is designing an enterprise web dashboard to display real-time utility outages, severe weather radar overlays, and repair crew deployments during major hurricane events.

Requirements & Sizing Calculation

• User Base: $50,000$ active municipal residents during peak storm hours.
• Peak Concurrency: Estimated at $10%$ of active users $\rightarrow 5,000\text{ concurrent users}$.
• User Behavior: Average think time between dashboard map interactions is estimated at $25\text{ seconds}$.
• Service Architecture:
  • Basemap: Pre-rendered vector tiles cached in a CDN ($0\text{ server load}$).
  • Outage Dynamic Layer: Lightweight vector feature service querying the enterprise geodatabase ($T_{\text{service}} = 0.20\text{ seconds}$ CPU time per request; average payload = $80\text{ KB}$).

Step-by-Step Sizing Execution

1. Calculate Peak Transaction Rate (TPS): $\text{Peak TPS} = \frac{5,000\text{ users}}{25\text{ seconds}} = 200\text{ TPS}$
2. Calculate Required GIS Application Server CPU Cores (at 75% target utilization): $\text{Required Cores} = \frac{200\text{ TPS} \times 0.20\text{ s}}{0.75} = \frac{40.0}{0.75} \approx 53.33\text{ Cores} \longrightarrow 56\text{ Cores}$ Design Recommendation: Provision a cluster of 7 GIS application server nodes, each equipped with 8 dedicated cores (yielding 56 total cores).
3. Calculate Required Network Bandwidth: $\text{Bandwidth (Mbps)} = \frac{200\text{ TPS} \times 80\text{ KB} \times 8}{1,000} = 128\text{ Mbps}$ Applying a $1.5\times$ safety factor for burst traffic yields a minimum required outward network pipe of $192\text{ Mbps}$ (or provisioning edge caching via a CDN to absorb $90%$ of the payload volume).

---

9. Common Exam Traps & Pitfalls

[!CAUTION] Exam Trap 16.1.1: Sizing Infrastructure for Named Users Instead of Concurrent Transactions. A recurring GISP exam trap presents an organization with 10,000 named users and asks how many cores are required. Candidates who divide named users directly into server capacity fail the question. Hardware sizing is strictly driven by Peak Concurrent Users and User Think Time, which determine Transactions Per Second (TPS). Always convert named users to active users, apply a concurrency ratio (typically 10-20%), and divide by think time to find TPS.

[!CAUTION] Exam Trap 16.1.2: Solving WAN Latency with Bandwidth Upgrades. When remote desktop GIS users experience unacceptably slow map drawing and frozen attribute tables over a 50 Mbps WAN/VPN connection, recommending a bandwidth upgrade to 1 Gbps is an incorrect answer! The root cause is network propagation latency (RTT) and chatty client-server SQL database requests, not bandwidth saturation. The correct architectural remedy is deploying virtualized desktops (VDI) located adjacent to the database on the LAN or migrating desktop tools to web service REST endpoints.

[!CAUTION] Exam Trap 16.1.3: Conflating RTO and RPO in Disaster Recovery Questions. Remember the fundamental direction of each metric:

• RTO (Recovery Time Objective): Looks FORWARD into the future. It is the time clock ticking until services are restored (downtime duration).
• RPO (Recovery Point Objective): Looks BACKWARD into the past. It is the timestamp of the last valid backup, quantifying the data loss window.