C4 Model Diagrams
Visualizing the SecurePay system hierarchy and interaction flow.
Level 1: System Context Diagram
The high-level view of how SecurePay interacts with users and external entities.
graph TD
User([Customer]) -- Uses --> SP[SecurePay System]
SP -- Sends Notifications --> Email[External Email System]
SP -- Verifies Identity --> IDP[External Auth Provider]
style SP fill:#0f172a,color:#fff,stroke:#3b82f6,stroke-width:2px
Level 2: Container Diagram
The microservices architecture, data stores, and message brokers within the SecurePay boundary.
graph TB
subgraph SecurePay_Boundary [SecurePay System]
AGW[API Gateway - Go] -- gRPC/mTLS --> PS[Payment Service - Go]
AGW -- gRPC/mTLS --> AS[Account Service - Go]
PS -- gRPC/mTLS --> AS
PS -- Publishes Events --> Kafka[(Kafka Broker)]
AS -- Consumes Events --> Kafka
NS[Notification Service - Java] -- Consumes Events --> Kafka
PS -- Persistent Storage --> PDB[(PostgreSQL)]
AS -- Persistent Storage --> PDB
AS -- Caching --> Redis[(Redis Cache)]
PS -- Idempotency --> Redis
SPIRE[SPIRE Server] -. Issues SVIDs .-> AGW
SPIRE -. Issues SVIDs .-> PS
SPIRE -. Issues SVIDs .-> AS
end
User([Customer]) -- HTTPS/JWT --> AGW
NS -- Logs/Mock --> Email[Email System]
style AGW fill:#1e293b,color:#fff
style PS fill:#1e293b,color:#fff
style AS fill:#1e293b,color:#fff
style NS fill:#1e293b,color:#fff
style PDB fill:#334155,color:#fff
style Redis fill:#334155,color:#fff
style Kafka fill:#334155,color:#fff
style SPIRE fill:#475569,color:#fff,stroke-dasharray: 5 5
Infrastructure: Kubernetes Deployment Diagram
The mapping of containers to Kubernetes resources across different namespaces.
graph TB
subgraph K8s_Cluster [Kubernetes Cluster / Minikube]
subgraph NS_Spire [Namespace: spire]
SS[SPIRE Server]
SA[SPIRE Agent]
end
subgraph NS_Default [Namespace: default]
subgraph Pod_AGW [Pod: api-gateway]
C_AGW[Container: Go App]
S_AGW[Sidecar: Spire Agent]
end
subgraph Pod_PS [Pod: payment-service]
C_PS[Container: Go App]
S_PS[Sidecar: Spire Agent]
end
subgraph Pod_AS [Pod: account-service]
C_AS[Container: Go App]
S_AS[Sidecar: Spire Agent]
end
subgraph Pod_NS [Pod: notification-service]
C_NS[Container: Java App]
end
subgraph Pod_Kafka [Pod: Kafka]
DB_Kafka[(Kafka Topic)]
end
subgraph Pod_Redis [Pod: Redis]
DB_Redis[(Redis Cache)]
end
subgraph Pod_DB [Pod: Postgres]
DB_PG[(PG Data)]
end
end
end
SA -- Health Check --> SS
S_AGW -. SVID .-> SA
S_PS -. SVID .-> SA
S_AS -. SVID .-> SA
C_AGW -- gRPC/mTLS --> C_PS
C_PS -- Events --> DB_Kafka
DB_Kafka -- Events --> C_AS
style NS_Spire fill:#f1f5f9,stroke:#64748b,stroke-dasharray: 5 5
style NS_Default fill:#f8fafc,stroke:#3b82f6
style Pod_AGW fill:#fff,stroke:#1e293b
style Pod_PS fill:#fff,stroke:#1e293b
style Pod_AS fill:#fff,stroke:#1e293b
style Pod_NS fill:#fff,stroke:#1e293b
The Detailed Payment Flow
1
External Request: The Customer initiates a payment via the Mobile/Web App,
sending a POST request to
/v1/payments with a Bearer JWT.
2
API Gateway: Validates the JWT, checks rate limits, and looks up the target
service. It uses a SPIFFE SVID to establish an mTLS connection to the Payment
Service.
3
Idempotency Check: The Payment Service checks Redis using the
Idempotency-Key from the header to ensure the request hasn't been processed
already.
4
Balance Validation: Payment Service calls the Account Service via gRPC to
verify funds. Account Service checks Redis (Read-Aside) first, then falls back
to PostgreSQL.
5
Transaction Initialization: Payment Service records the transaction in its
schema as
PENDING and returns an immediate response to the Gateway.
6
Event Bus: Payment Service publishes a
PaymentInitiated event to
the Kafka topic.
7
Asynchronous Processing:
- Account Service consumes the event, updates balances in DB using Optimistic Locking, and clears the Redis cache.
- Notification Service consumes the event and triggers an alert for the user.