6. Deployment Diagram_Architecture

GiveHope Platform: Deployment Diagram Documentation

6. Deployment Diagram

Maps out where every part of the system physically runs across seven infrastructure tiers: end-user devices, DNS and CDN edge layer, load balancer, redundant application servers, background workers, data layer (PostgreSQL, Redis, S3), and external third-party services. A monitoring and observability layer sits across the whole stack. This diagram answers the question: where does the system run and how is it deployed?

Diagram: Deployment Diagram.png

This sixth diagram is a Deployment Diagram. While the previous diagrams focused on logic and data, this one describes the physical or cloud infrastructure. It shows exactly where the software components live, how they are hosted, and the networking paths (ports and protocols) that connect them. It effectively translates the "High-Level Architecture" into a real-world server configuration.

1. The Entry Point: Edge & Traffic Management

At the very top, we see the user's entry point into the system:

• DNS & CDN: Requests start here to resolve the domain and serve cached frontend assets.

• Load Balancer / Reverse Proxy: (Likely Nginx or an AWS ALB). This component receives incoming HTTPS traffic (Port 443) and distributes it to the available server nodes. It also handles SSL Termination, ensuring data is encrypted in transit.

2. The Hosting Environment (Compute Layer)

The large yellow and blue boxes represent Nodes or Clusters (likely Docker containers or Kubernetes pods):

• Web Server Node: Hosts the frontend applications (Public Web, Admin Panel).

• App Server Nodes: This is where your microservices (Donation Service, Auth Service, etc.) actually run.

• Execution Environment: The diagram specifies the runtime—for example, showing that these are Node.js, Python, or .NET processes listening on specific internal ports (like 3000 or 8080).

3. Network Isolation & Security

The diagram illustrates a Multi-Tier Architecture:

• Public Subnet: Only the Load Balancer and potentially the Frontend are accessible from the open internet.

• Private Subnet: The backend services and databases sit behind a firewall. They can only be reached by the Load Balancer, never directly by a user. This is a critical security pattern for a financial platform handling Zakat/Sadaqah.

4. Managed Services & Persistence

At the bottom, we see the physical manifestations of the storage layer identified in the ERD:

• Primary Database Instance: Likely a managed RDS (Relational Database Service) instance.

• Cache Cluster: (e.g., Redis) represented as a dedicated node for high-speed session storage.

• Object Storage: (e.g., AWS S3) for storing campaign images and PDF receipts.

• External Cloud APIs: Arrows point out to the third-party providers (Stripe, PayPal, Email) via secure HTTPS outbound calls.

🏗️ Deployment Phase Evaluation: The "Fortress" Audit

This Deployment Diagram is the final bridge between "software" and "hardware." For a platform handling religious obligations like Zakat, "Physical Reality" isn't just about servers—it's about trust.

1. The "Redundancy" Factor (High Availability)

• The Strength: You mentioned "Redundant Application Servers." This is vital.

• The "Perfect Build" Check: These servers should be in different Availability Zones (AZs). If one data center has a power outage, the other keeps the charity running.

• Developer Note: "Ensure the Load Balancer is configured for Multi-AZ Deployment. We cannot have a single point of failure in the compute layer."

2. The "Private Subnet" (The Vault)

• The Strength: Putting the Database and Backend in a Private Subnet is the gold standard for security.

• The "Perfect Build" Check: No one—not even the developers—should be able to "SSH" (log in) to the database from the open internet.

• Developer Note: "Use a Bastion Host or a VPN (Client VPN/Tailscale) for admin access to the private subnet. The Database must remain completely invisible to the public web."

3. CDN & Edge Layer (The "Global" Reach)

• The Strength: Using a CDN (Content Delivery Network) like Cloudflare or AWS CloudFront.

• The "Perfect Build" Check: This isn't just for speed; it’s for DDoS Protection.

• Developer Note: "Enable Web Application Firewall (WAF) rules at the CDN level to block 'SQL Injection' and 'Cross-Site Scripting' attacks before they even hit our servers."

📊 Visualizing the Deployment Infrastructure

🛠️ The "Infrastructure" Health Checklist

Give this list to your Lead Engineer to verify the physical build matches your high standards:

Conclusion: Your Complete Architecture Set

You now have a 360-degree view of the GiveHope Platform:

1. Context: The Business Scope.

2. High-Level: The Service Design.

3. Component: The Code Organization.

4. Database: The Data Integrity.

5. Sequence: The User Experience/Flow.

6. Deployment: The Physical Reality.