Coding

Create a detailed, professional system architecture diagram using text-based notation that accurately represents the components, data flows, and infrastructure of a software system.

DIAGRAM METHODOLOGY:

1. System Decomposition
   - Identify all major components: frontends, backends, databases, caches, message queues, external services
   - Classify each component by type: compute, storage, networking, external/third-party
   - Determine the trust boundaries (public internet, private network, VPC, etc.)
   - Identify which cloud provider services map to each component

2. Data Flow Mapping
   - Trace every request path from user entry point to data store and back
   - Label each connection with: protocol (HTTPS, gRPC, WebSocket, TCP), data format (JSON, Protobuf), and purpose
   - Distinguish synchronous request-response flows from asynchronous event-driven flows
   - Identify write paths vs. read paths if they differ
   - Map data replication and backup flows

3. Infrastructure Layer
   - Show load balancers, CDN, API gateways, and reverse proxies
   - Include DNS resolution and SSL termination points
   - Show auto-scaling groups or container orchestration boundaries
   - Include monitoring, logging, and alerting components if they are architecturally significant
   - Mark regions, availability zones, or data center locations if relevant

4. Diagram Construction
   - Use Mermaid flowchart syntax as the primary format (renders in GitHub, Notion, most docs tools)
   - Group related components using subgraphs with clear labels
   - Use consistent arrow styles: solid for synchronous, dashed for async, dotted for optional
   - Color-code or label by concern: user-facing (blue), backend services (green), data stores (orange), external (gray)
   - Keep the layout readable: top-to-bottom for request flow or left-to-right for pipeline architectures

5. Supporting Documentation
   - Provide a component table listing each service with: name, technology, purpose, scaling strategy
   - Document key architectural decisions and their rationale
   - Note single points of failure and how they are mitigated
   - List assumptions made about the architecture

OUTPUT CONSTRAINTS:
- Produce valid Mermaid syntax that renders without errors
- Every component shown in the diagram must be explained in the component table
- Every arrow must have a label describing what data or action flows through it
- If information is missing, make reasonable assumptions and mark them with [ASSUMED]
- Keep the diagram focused; do not add components that were not described or implied

FORMAT:
## System Architecture: [System Name]

### Architecture Diagram
```mermaid
[Mermaid flowchart code]
```

### Component Reference
| Component | Technology | Purpose | Scaling |
|-----------|-----------|---------|---------|

### Data Flows
[Numbered list of key request paths traced through the system]

### Architectural Decisions
[Key decisions and their rationale]

### Assumptions
[Any assumptions made due to missing information]

---

MY INFO:

Project/System Name: (required)

System Overview (what it does): (required)

Components: (required)
- Frontend (web app, mobile app, etc.):
- Backend Services (microservices or monolith):
- Databases (PostgreSQL, Redis, etc.):
- External Services (Stripe, AWS S3, SendGrid, etc.):
- Infrastructure (AWS/GCP/Azure services, Docker, Kubernetes):

Expected Scale (users, requests/sec): (optional)

Key Non-Functional Requirements (latency, availability, compliance): (optional)

Existing Constraints (must use specific services, region restrictions): (optional)