# 4. Solution Strategy

## 4.1 Fundamental Decisions

| Goal | Strategy |
|------|----------|
| Maintainability | Three bounded contexts as separate FastAPI applications, each owning its PostgreSQL schema |
| Performance | Async I/O throughout (FastAPI + asyncpg); feed aggregation via pre-computed read models |
| Scalability | Stateless API processes; horizontal scaling behind a load balancer |
| Security | JWT-based authentication issued by the Users context; validated by all other contexts |
| Developer experience | OpenAPI specs auto-generated by FastAPI; React frontend consumes typed API clients |

## 4.2 Architecture Style

Modular monorepo deployment: all three bounded contexts run as independent FastAPI processes but are developed in a single repository. This allows independent scaling while keeping cross-team coordination simple at the current stage.

## 4.3 Key Technology Decisions

| Decision | Choice | Reason |
|----------|--------|--------|
| Web framework | FastAPI | Async, automatic OpenAPI, Pydantic validation |
| Database | PostgreSQL (one schema per context) | ACID guarantees, rich query support, familiar tooling |
| ORM / query layer | SQLAlchemy 2 (async) | Pythonic, supports async, works well with FastAPI |
| Migrations | Alembic | Standard tool for SQLAlchemy projects |
| Frontend | React + TypeScript | Type-safe UI, large ecosystem |
| Auth | JWT (RS256) | Stateless, verifiable across services without shared DB |

## 4.4 How the Strategy Meets the Quality Goals

| Quality Goal | How it is addressed |
|-------------|---------------------|
| Availability | Stateless services allow restarts and rolling updates without downtime |
| Performance | Async handlers + connection pooling keep latency low under load |
| Scalability | Each context scales independently; no shared mutable state |
| Security | RS256 JWTs; each context validates tokens locally |
| Maintainability | Hard context boundaries enforced by separate schemas and API contracts |