Differences

This shows you the differences between two versions of the page.

--- reference:system-architecture:infrastructure [2025/08/26 22:00] – runarbe
+++ reference:system-architecture:infrastructure [2025/08/26 22:10] (current) – runarbe
@@ Line 1: / Line 1: @@
-====== Infrastructure Layer: A means to ensure availability of addressing data ======
+====== Infrastructure Layer ======
+//— A means to ensure availability of addressing data//
 The database and applications must be run from some server infrastructure. It is assumed that the system at most may have some 120 concurrent users working in 63 different wilayat, municipalities, governorate offices as well as centrally at Ministry of Housing and Urban Planning.
@@ Line 42: / Line 44: @@
 For a system accommodating 120 concurrent users and managing substantial datasets, a robust cloud server infrastructure is essential. Below are the recommended specifications based on the criteria provided:
-Processor
+=== Processor ===
   * CPU Type and Frequency: Utilise Intel Xeon or AMD EPYC processors with a minimum base frequency of 2.5 GHz.
   * Number of CPU Cores: Opt for a configuration with 16 to 32 CPU cores to ensure responsiveness under load.
-Memory
+=== Memory ===
   * Amount of RAM: A minimum of 64 GB RAM is advisable for efficient data handling and application performance.
-Storage
+=== Storage ===
   * Type of Storage: Implement NVMe SSD storage for fast data retrieval and enhanced system performance.
@@ Line 59: / Line 61: @@
   * Partitioning: Ensure separate partitions for system files, application data, and logs to enhance security and manageability.
-System Configuration
+=== System Configuration ===
   * Network Configuration: Optimise NGINX for high concurrency by adjusting worker processes and connections.
@@ Line 65: / Line 67: @@
   * Performance Monitoring: Implement continuous monitoring and scaling to adapt to workload variations.
-Example Cloud Server Types
+=== Example Cloud Server Types ===
 If the applications will be served in the cloud, these are examples of standard configurations offered by the leading cloud service providers. If the solutions are to be hosted on premise, equivalent hardware/virtual machines may be used.
@@ Line 79: / Line 81: @@
 Network infrastructure plays a crucial role in supporting the National Addressing System. When considering the specifications for such an environment, it is essential to focus on parameters such as bandwidth, uptime, and latency to ensure optimal performance. Below are recommendations suited for the outlined requirements:
-Bandwidth requirements
+=== Bandwidth requirements ===
-  *
+  * For handling a variety of operations, including a database server, file server, and web application server with Docker containers, a robust bandwidth is essential.
+  * A dedicated internet connection with a minimum of 1 Gbps is advisable. This should accommodate data-intensive tasks, concurrent user access, and data retrieval from large relational tables effectively.
+  * Ensure scalable bandwidth options to accommodate future growth in user number or data volume without degradation in service quality.
-For handling a variety of operations, including a database server, file server, and web application server with Docker containers, a robust bandwidth is essential.
+=== Uptime requirements ===
-  *
+  * The system should aim for an uptime of at least 99.9%. This reflects high availability, ensuring minimal downtime throughout the year.
+  * Implement redundant network paths and failover strategies to maintain continuity. Using high-availability network infrastructure components such as clustered firewalls and redundant power supplies is also beneficial.
-A dedicated internet connection with a minimum of 1 Gbps is advisable. This should accommodate data-intensive tasks, concurrent user access, and data retrieval from large relational tables effectively.
+=== Latency requirements ===
-  *
+  * Low latency is critical for user interactions, particularly when serving web and GIS applications with real-time data processing needs.
+  * Target a network latency of less than 100 milliseconds for end-to-end communication within Oman.
-Ensure scalable bandwidth options to accommodate future growth in user number or data volume without degradation in service quality.
+  * Utilise modern routing protocols and optimisation techniques to ensure that data packets traverse the most efficient pathways, reducing potential delays.
-Uptime requirements
-  *
-The system should aim for an uptime of at least 99.9%. This reflects high availability, ensuring minimal downtime throughout the year.
-  *
-Implement redundant network paths and failover strategies to maintain continuity. Using high-availability network infrastructure components such as clustered firewalls and redundant power supplies is also beneficial.
-Latency requirements
-  *
-Low latency is critical for user interactions, particularly when serving web and GIS applications with real-time data processing needs.
-  *
-Target a network latency of less than 100 milliseconds for end-to-end communication within Oman.
-  *
-Utilise modern routing protocols and optimisation techniques to ensure that data packets traverse the most efficient pathways, reducing potential delays.
 Always consider potential future growth and adjust server capacities as necessary to maintain system performance.
-  -
+===== 4. Client requirements =====
-Client requirements
 The requirements only apply for users who are going to have roles in creating or maintaining addresses or who wish to establish integrations where they interact with the addressing API.
@@ Line 129: / Line 108: @@
 When building a business-oriented React web application that relies heavily on web maps (both PBF vector tiles and PNG raster tiles), it’s important to establish baseline client-side requirements to ensure acceptable performance and user experience. Rendering vector tiles in the browser involves client-side decoding (often via WebGL) and styling, while raster tiles require frequent image loading. Below are starting-point recommendations for CPU, RAM, screen resolution, browsers, and network bandwidth on client machines.
-CPU (Processor)
+=== CPU (Processor) ===
-  *
+  * Requirement: A modern multi-core CPU with good single-thread performance (e.g., recent Intel Core i5/i7 or AMD Ryzen 5/7 equivalents or better).
+  * Rationale: Vector tile rendering is performed client-side via WebGL or Canvas, which benefits from both GPU acceleration and CPU tasks such as tile parsing and layout updates. Lower-end or very old CPUs may exhibit sluggish pan/zoom and style updates. Raster tile handling (downloading and compositing PNGs) also uses CPU for decoding image data and updating the DOM/canvas. Modern multi-core chips help when multiple browser tabs or other applications run concurrently.
-Requirement: A modern multi-core CPU with good single-thread performance (e.g., recent Intel Core i5/i7 or AMD Ryzen 5/7 equivalents or better).
+=== Recommendations: ===
-  *
+  - Minimum: Dual-core CPU at ~2.0–2.5 GHz (e.g., older Intel Core i3 or equivalent), but expect limited performance when many layers/features are shown or on complex style changes.
+  - Recommended: Quad-core or better at ~3.0 GHz or higher. This ensures smoother interactions, especially when the map has many vector layers, dynamic styling, or frequent updates (e.g., real-time data overlays).
-Rationale: Vector tile rendering is performed client-side via WebGL or Canvas, which benefits from both GPU acceleration and CPU tasks such as tile parsing and layout updates. Lower-end or very old CPUs may exhibit sluggish pan/zoom and style updates. Raster tile handling (downloading and compositing PNGs) also uses CPU for decoding image data and updating the DOM/canvas. Modern multi-core chips help when multiple browser tabs or other applications run concurrently.
+=== GPU / Graphics (indirectly via browser) ===
-  *
+  * Requirement: Hardware-accelerated WebGL support in the GPU/driver, available in all modern integrated GPUs (Intel HD/UHD Graphics of recent generations) and discrete GPUs.
+  * Rationale: Libraries like ArcGIS, OpenLayers, Mapbox GL JS, MapLibre, and similar rely on WebGL to render vector tiles efficiently on the GPU. Without hardware acceleration, performance may degrade significantly, and some browsers may fall back to software rendering (which can be slow).
+  * Recommendations: Use client machines whose browsers report “Hardware accelerated” for WebGL contexts. Encourage users to keep GPU drivers up to date. Test on representative hardware to ensure the map renders smoothly.
-Recommendations:
+=== RAM (Memory) ===
-  -
+  * Requirement: Sufficient system RAM to accommodate the browser, OS, and the mapping app’s memory footprint. Vector tile rendering can consume memory for tile caches, style data, and map state.
+  * Rationale: Browsers cache tiles and resources in memory; having insufficient RAM can cause swapping, leading to lagging interactions, especially when multiple tabs or heavy pages are open. Complex React applications (with state management, large data arrays, and map libraries) benefit from more headroom.
+  * Recommendations:
+      * Minimum: 4 GB of RAM free for the browser process (e.g., on a system with at least 8 GB total RAM, leaving room for OS and background tasks). With only 4 GB total RAM on the machine, mapping performance will suffer if the user runs other demanding apps simultaneously.
+      * Recommended: 8 GB to 16 GB total system RAM, providing at least 6 GB free for the browser when the mapping app is active. This supports multiple open tabs, larger tile caches, and additional data overlays without excessive garbage collection or swapping.
-Minimum: Dual-core CPU at ~2.0–2.5 GHz (e.g., older Intel Core i3 or equivalent), but expect limited performance when many layers/features are shown or on complex style changes.
+=== Screen resolution and display ===
-  -
+  * Requirement: A responsive layout that adapts to various screen sizes, with testing on the effective minimum resolution expected in your user base.
+  * Rationale: Business users may work on laptops, desktops, or even high-resolution monitors; the mapping interface should leverage available screen real estate but remain usable at lower resolutions.
+  * Recommendations:
+      * Minimum supported viewport: 1366 × 768 CSS pixels (common baseline for many business web apps)
+      * Recommended viewport: 1920 × 1080 (typical desktop/laptop higher end)
-Recommended: Quad-core or better at ~3.0 GHz or higher. This ensures smoother interactions, especially when the map has many vector layers, dynamic styling, or frequent updates (e.g., real-time data overlays).
+=== Client browsers (Software) ===
-GPU / Graphics (indirectly via browser)
+  * Requirement: Modern, standards-compliant browsers with up-to-date WebGL and JavaScript performance.
+  * Rationale: Vector tile libraries rely on ES6+ JavaScript features, WebGL 1.0 (at least), and often Web Workers. Older browsers (e.g., IE11) may lack support or require polyfills, reducing performance and sometimes preventing core features. Frequent browser updates include performance and security patches important for business applications.
+  * Recommendations:
+      * Supported Browsers: Latest two major versions of Google Chrome, Mozilla Firefox, Microsoft Edge (Chromium-based), and Apple Safari (on macOS)
+      * Enterprise Constraints: If corporate policies mandate specific browser versions, ensure the minimum supported versions still have required WebGL/ES6 support. If not, consider polyfills or limiting features (e.g., use raster tiles fallback if vector rendering is unavailable).
-  *
+=== Client network bandwidth and latency ===
-Requirement: Hardware-accelerated WebGL support in the GPU/driver, available in all modern integrated GPUs (Intel HD/UHD Graphics of recent generations) and discrete GPUs.
+  * Requirement: Broadband-speed connectivity with reasonable latency to tile servers (self-hosted or third-party).
+  * Rationale: Vector tiles (PBF) are typically well-compressed (often ~10–50 KB per tile depending on zoom level and data complexity), but many tiles load as users pan/zoom, plus style and font resources. Raster PNG tiles can be larger (~20–100 KB each). Slow networks will cause delayed tile loads, leading to blank or low-detail map areas during navigation. Latency affects perceived responsiveness: high round-trip times delay tile requests.
+  * Recommendations:
+      * Minimum: Sustained download speeds of at least 5 Mbps, with latency under ~100 ms to the tile server endpoint. On slower links (e.g., 3G/4G intermittent, VPNs), consider (a) lowering initial zoom or extent to prefetch fewer tiles, (b) using vector tiles with simplified style to reduce tile count or size and © implementing tile caching (browser cache, service workers) and using HTTP/2 for concurrent requests.
+      * Recommended: 10 Mbps or higher with latency under ~50 ms for good user experience, particularly if the app loads many overlays or high-zoom-level detail.
+      * Offline or Low-bandwidth Strategies: If clients occasionally have poor connectivity, provide fallback UI: e.g., show a message, allow offline cached tiles (via service workers), or reduce map detail (fewer tile layers) when bandwidth is constrained.
-  *
+Summary client requirements table (baseline vs. recommended)
-Rationale: Libraries like ArcGIS, OpenLayers, Mapbox GL JS, MapLibre, and similar rely on WebGL to render vector tiles efficiently on the GPU. Without hardware acceleration, performance may degrade significantly, and some browsers may fall back to software rendering (which can be slow).
+^ \\ Component^ \\ Minimum^ \\ Recommended|
+^ \\ CPU| \\ Dual-core ~2.0–2.5 GHz| \\ Quad-core ~3.0 GHz+|
+^ \\ GPU/WebGL| \\ Basic WebGL support| \\ Up-to-date GPU drivers with hardware accel.|
+^ \\ RAM| \\ ~4 GB available for browser| \\ 8–16 GB total system RAM|
+^ \\ Screen Resolution| \\ 1366 × 768 CSS pixels viewport| \\ 1920 × 1080 pixels viewport|
+^ \\ Browsers| \\ Modern: Chrome/Firefox/Edge/Safari| \\ Latest 2 major versions; ensure WebGL enabled|
+^ \\ Network Bandwidth| \\ ≥5 Mbps download, <100 ms latency| \\ ≥10 Mbps download, <50 ms latency|
-  *
+===== 5. Data governance and security measures =====
-Recommendations:
-  -
-Use client machines whose browsers report “Hardware accelerated” for WebGL contexts. Encourage users to keep GPU drivers up to date. Test on representative hardware to ensure the map renders smoothly.
-RAM (Memory)
-  *
-Requirement: Sufficient system RAM to accommodate the browser, OS, and the mapping app’s memory footprint. Vector tile rendering can consume memory for tile caches, style data, and map state.
-  *
-Rationale: Browsers cache tiles and resources in memory; having insufficient RAM can cause swapping, leading to lagging interactions, especially when multiple tabs or heavy pages are open. Complex React applications (with state management, large data arrays, and map libraries) benefit from more headroom.
-  *
-Recommendations:
-  -
-Minimum: 4 GB of RAM free for the browser process (e.g., on a system with at least 8 GB total RAM, leaving room for OS and background tasks). With only 4 GB total RAM on the machine, mapping performance will suffer if the user runs other demanding apps simultaneously.
-  -
-Recommended: 8 GB to 16 GB total system RAM, providing at least 6 GB free for the browser when the mapping app is active. This supports multiple open tabs, larger tile caches, and additional data overlays without excessive garbage collection or swapping.
-Screen resolution and display
-  *
-Requirement: A responsive layout that adapts to various screen sizes, with testing on the effective minimum resolution expected in your user base.
-  *
-Rationale: Business users may work on laptops, desktops, or even high-resolution monitors; the mapping interface should leverage available screen real estate but remain usable at lower resolutions.
-  *
-Recommendations:
-  -
-Minimum supported viewport: 1366 × 768 CSS pixels (common baseline for many business web apps)
-  -
-Recommended viewport: 1920 × 1080 (typical desktop/laptop higher end)
-Client browsers (Software)
-  *
-Requirement: Modern, standards-compliant browsers with up-to-date WebGL and JavaScript performance.
-  *
-Rationale: Vector tile libraries rely on ES6+ JavaScript features, WebGL 1.0 (at least), and often Web Workers. Older browsers (e.g., IE11) may lack support or require polyfills, reducing performance and sometimes preventing core features. Frequent browser updates include performance and security patches important for business applications.
-  *
-Recommendations:
-  -
-Supported Browsers: Latest two major versions of Google Chrome, Mozilla Firefox, Microsoft Edge (Chromium-based), and Apple Safari (on macOS)
-  -
-Enterprise Constraints: If corporate policies mandate specific browser versions, ensure the minimum supported versions still have required WebGL/ES6 support. If not, consider polyfills or limiting features (e.g., use raster tiles fallback if vector rendering is unavailable).
-Client network bandwidth and latency
-  *
-Requirement: Broadband-speed connectivity with reasonable latency to tile servers (self-hosted or third-party).
-  *
-Rationale: Vector tiles (PBF) are typically well-compressed (often ~10–50 KB per tile depending on zoom level and data complexity), but many tiles load as users pan/zoom, plus style and font resources. Raster PNG tiles can be larger (~20–100 KB each). Slow networks will cause delayed tile loads, leading to blank or low-detail map areas during navigation. Latency affects perceived responsiveness: high round-trip times delay tile requests.
-  *
-Recommendations:
-  -
-Minimum: Sustained download speeds of at least 5 Mbps, with latency under ~100 ms to the tile server endpoint. On slower links (e.g., 3G/4G intermittent, VPNs), consider (a) lowering initial zoom or extent to prefetch fewer tiles, (b) using vector tiles with simplified style to reduce tile count or size and © implementing tile caching (browser cache, service workers) and using HTTP/2 for concurrent requests.
-  -
-Recommended: 10 Mbps or higher with latency under ~50 ms for good user experience, particularly if the app loads many overlays or high-zoom-level detail.
-  -
-Offline or Low-bandwidth Strategies: If clients occasionally have poor connectivity, provide fallback UI: e.g., show a message, allow offline cached tiles (via service workers), or reduce map detail (fewer tile layers) when bandwidth is constrained.
-Summary table (baseline vs. recommended)
-| \\ Component| \\ Minimum| \\ Recommended|
-| \\ CPU| \\ Dual-core ~2.0–2.5 GHz| \\ Quad-core ~3.0 GHz+|
-| \\ GPU/WebGL| \\ Basic WebGL support| \\ Up-to-date GPU drivers with hardware accel.|
-| \\ RAM| \\ ~4 GB available for browser| \\ 8–16 GB total system RAM|
-| \\ Screen Resolution| \\ 1366 × 768 CSS pixels viewport| \\ 1920 × 1080 pixels viewport|
-| \\ Browsers| \\ Modern: Chrome/Firefox/Edge/Safari| \\ Latest 2 major versions; ensure WebGL enabled|
-| \\ Network Bandwidth| \\ ≥5 Mbps download, <100 ms latency| \\ ≥10 Mbps download, <50 ms latency|
-  -
-Data governance and security measures
 In developing the National Addressing System in Oman, maintaining data governance and implementing robust security measures are critical considerations. While it is important not to restrict access to addressing data, prioritising data integrity remains essential. Ensuring that data is accurate, reliable, and trustworthy requires specific strategies.
@@ Line 283: / Line 177: @@
 To maintain the integrity of addressing data, especially in distributed systems, ensuring data concurrency across any distributed copies or caches is crucial. Data concurrency will ensure that different versions of the data remain consistent with each other, preventing discrepancies and potential data conflicts.
-  -
+===== 6. Service Level Requirements for Infrastructure =====
-Service Level Requirements for Infrastructure
 To ensure continuous availability, data integrity, and resilience of the National Addressing System (NAS), the underlying infrastructure must meet clearly defined service level requirements. These requirements are particularly critical given the national importance of address data and the need to support both operational continuity and rapid recovery in the event of an incident.
-Disaster Recovery
+=== Disaster Recovery ===
 A comprehensive disaster recovery plan will be established to protect the NAS against events such as hardware failures, data corruption, natural disasters, and cyber incidents. The plan will include regular, automated backups of all critical data and system configurations, secure offsite storage, and well-documented procedures for restoring service.
-Recovery Time Objective (RTO)
+=== Recovery Time Objective (RTO) ===
 The Recovery Time Objective defines the maximum acceptable duration for restoring full service following a disruption. For the NAS, the RTO shall not exceed 4 hours for core database and API services, ensuring that essential address data and integrations remain available to users and stakeholders with minimal downtime. Routine tests of recovery procedures will be conducted to validate adherence to the RTO.
-Recovery Point Objective (RPO)
+=== Recovery Point Objective (RPO) ===
 The Recovery Point Objective specifies the maximum age of data that may be lost in the event of a failure. For the NAS, the RPO is set at 15 minutes, meaning that backup and replication strategies must ensure that, at most, only the last 15 minutes of transactions could be lost under worst-case scenarios. Incremental backups and near-real-time data replication will be employed to achieve this goal.
-Optional Multi-Region Deployment (Middle East/Europe)
+=== Optional Multi-Region Deployment (Middle East/Europe) ===
 For public facing applications that might be used by global audiences, it may be possible to further strengthen resilience by supporting geographic redundancy, such parts of the NAS infrastructure as is relevant may optionally be deployed in a multi-region configuration spanning the Middle East and Europe.