senior-architect

---
name: senior-architect
description: Use when designing system architecture, evaluating microservices vs monolith, choosing a database, planning scalability, or generating architecture/dependency diagrams and decisions.
category: Engineering
version: 1.0.0
tools: []
---

# Senior Architect

Architecture design and analysis methodology for informed technical decisions: system diagramming, dependency analysis, and pattern selection.

## Diagramming projects

When asked to visualize architecture, describe or produce diagram code in Mermaid, PlantUML, or ASCII, in one of three views:
- **Component view** — modules and their relationships (e.g., API Gateway → Auth Service → PostgreSQL)
- **Layer view** — presentation, business, and data layers
- **Deployment view** — deployment topology

## Dependency analysis

When reviewing a dependency tree, analyze for:
- **Circular dependencies** between modules (e.g., auth → user → permissions → auth) — flag and recommend extracting a shared interface to break the cycle
- **Coupling score (0–100)** — higher scores mean tighter coupling and lower team autonomy; a score around 70+ is moderate-to-concerning
- **Outdated / vulnerable packages** — flag with the CVE where known (e.g., lodash 4.17.15 → 4.17.21 fixes CVE-2020-8203)
- Package manager conventions: npm/yarn (package.json), Python (requirements.txt, pyproject.toml), Go (go.mod), Rust (Cargo.toml)

## Architecture assessment

When assessing an existing codebase:
- Detect the pattern in use (MVC, layered, hexagonal, microservices indicators) and state a confidence level
- Flag code-organization smells: god classes / oversized files (e.g., an 1,800+ line service file warrants splitting), mixed concerns (business logic embedded in controllers), and layer violations
- Recommend splitting oversized services, moving business logic out of controllers, and separating domain models from DTOs

## Database selection workflow

Walk through in order:
1. **Data characteristics** — structured with relationships and ACID transactions point to SQL; flexible/evolving schema, document-oriented, or time-series data point to NoSQL (time-series often wants a specialized store)
2. **Scale** — under 1M records, single region → PostgreSQL or MySQL. 1M–100M records, read-heavy → PostgreSQL with read replicas. Over 100M records, global distribution → CockroachDB, Spanner, or DynamoDB. High write throughput above 10K/sec → Cassandra or ScyllaDB
3. **Consistency** — strong consistency required → SQL or CockroachDB; eventual consistency acceptable → DynamoDB, Cassandra, or MongoDB
4. **Document the decision** as an ADR (Architecture Decision Record): context and requirements, options considered, decision and rationale, trade-offs accepted

Quick defaults: PostgreSQL for most applications, MongoDB for flexible document schemas, Redis for caching/sessions/real-time, DynamoDB for serverless AWS-native workloads, TimescaleDB for time-series with a SQL interface.

## Architecture pattern selection workflow

1. **Team size** — 1–3 developers → modular monolith. 4–10 developers → modular monolith or service-oriented. 10+ developers → consider microservices.
2. **Deployment requirements** — a single deployment unit is acceptable → monolith; independent scaling is needed → microservices; a mix → hybrid.
3. **Data boundaries** — a shared database is acceptable → monolith or modular monolith; strict data isolation is required → microservices with separate databases; event-driven communication fits the domain → event sourcing / CQRS.
4. **Match pattern to requirement** — rapid MVP → modular monolith; independent team deployment → microservices; complex domain logic → Domain-Driven Design; large gap between read and write volume → CQRS; audit-trail requirement → event sourcing; heavy third-party integration → hexagonal (ports & adapters).

## Monolith vs. microservices

Choose **monolith** when the team is small (under 10 developers), domain boundaries are still unclear, rapid iteration is the priority, operational complexity must be minimized, and a shared database is acceptable.

Choose **microservices** when teams can own services end-to-end, independent deployment is critical, components have genuinely different scaling requirements, technology diversity is needed, and domain boundaries are already well understood.

**Hybrid approach**: start with a modular monolith and extract a service only when (1) a module has significantly different scaling needs, (2) a team needs to deploy independently, or (3) a technology constraint forces separation.

## Tech stack coverage

Languages: TypeScript, JavaScript, Python, Go, Swift, Kotlin, Rust. Frontend: React, Next.js, Vue, Angular, React Native, Flutter. Backend: Node.js, Express, FastAPI, Go, GraphQL, REST. Databases: PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra. Infrastructure: Docker, Kubernetes, Terraform, AWS, GCP, Azure. CI/CD: GitHub Actions, GitLab CI, CircleCI, Jenkins.

For deep pattern trade-offs (9 named patterns), step-by-step system-design workflows, or technology decision matrices, search the Knowledge Base or @mention a specialized teammate.