Differences

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

--- reference:system-architecture:infrastructure [2025/08/26 22:05] – [Infrastructure Layer] runarbe
+++ reference:system-architecture:infrastructure [2025/08/26 22:10] (current) – runarbe
@@ Line 6: / Line 6: @@
 On top of that, there may be 1000s of users accessing the data retrieval and query interfaces in the API. The following hardware and networking infrastructure requirements are based on the above assumptions.
 ===== 1. Technical requirements specification for database server =====
@@ Line 45: / 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 62: / 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 68: / 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 82: / 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.
@@ Line 88: / Line 87: @@
   * Ensure scalable bandwidth options to accommodate future growth in user number or data volume without degradation in service quality.
-Uptime requirements
+=== 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
+=== Latency requirements ===
   * Low latency is critical for user interactions, particularly when serving web and GIS applications with real-time data processing needs.
@@ Line 109: / 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.
-Recommendations:
+=== 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).
-GPU / Graphics (indirectly via browser)
+=== 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.
@@ Line 125: / Line 124: @@
   * 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)
+=== 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.
@@ Line 133: / Line 132: @@
       * 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
+=== 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.
@@ Line 141: / Line 140: @@
       * Recommended viewport: 1920 × 1080 (typical desktop/laptop higher end)
-Client browsers (Software)
+=== Client browsers (Software) ===
   * Requirement: Modern, standards-compliant browsers with up-to-date WebGL and JavaScript performance.
@@ Line 149: / Line 148: @@
       * 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
+=== Client network bandwidth and latency ===
   * Requirement: Broadband-speed connectivity with reasonable latency to tile servers (self-hosted or third-party).
@@ Line 158: / Line 157: @@
       * 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)
+Summary client requirements table (baseline vs. recommended)
-| \\ Component| \\ Minimum| \\ Recommended|
+^ \\ Component^ \\ Minimum^ \\ Recommended|
-| \\ CPU| \\ Dual-core ~2.0–2.5 GHz| \\ Quad-core ~3.0 GHz+|
+^ \\ 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.|
+^ \\ 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|
+^ \\ RAM| \\ ~4 GB available for browser| \\ 8–16 GB total system RAM|
-| \\ Screen Resolution| \\ 1366 × 768 CSS pixels viewport| \\ 1920 × 1080 pixels viewport|
+^ \\ Screen Resolution| \\ 1366 × 768 CSS pixels viewport| \\ 1920 × 1080 pixels viewport|
-| \\ Browsers| \\ Modern: Chrome/Firefox/Edge/Safari| \\ Latest 2 major versions; ensure WebGL enabled|
+^ \\ 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|
+^ \\ Network Bandwidth| \\ ≥5 Mbps download, <100 ms latency| \\ ≥10 Mbps download, <50 ms latency|
-===== Data governance and security measures =====
+===== 5. 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 178: / 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.
-===== Service Level Requirements for Infrastructure =====
+===== 6. 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.