Monolith Architecture and Scaling Architect

Wrote docs/architecture/monolith-architect/00-overview/monolith-architect-overview.md and docs/architecture/monolith-architect/verification/fitness-self-check.md. Complete Monolith architecture specification establishing clean layer boundaries, horizontal compute scaling, shared Aurora database connection pooling, and sub-45ms execution.

---

skill: monolith-architect

Monolith Architecture: National Auto Insurance Platform [MONOARCH-INS-001]

Summary

This specification establishes the unified Monolith architecture, structural layer boundaries, horizontal compute scaling model, and shared database governance for auto-insurance-policy-monolith v3.0 under run ID auto-mono-arch-001. It governs policy quoting, policy lifecycle administration, billing collections, and first-notice-of-loss claims across 3.8 million active policyholders with 24 developers organized into 3 product squads. It decisively resolves the operational thrashing demonstrated in incident INC-4932 (where attempting to manage 14 experimental microservices with only 24 developers caused 18-minute deployment pipeline freezes and $1.4M in wasted cloud infrastructure costs). The architecture establishes a

Unified Monolithic Application Core deployed as a single optimized JVM artifact across horizontal stateless AWS ECS compute tasks, leverages a single

AWS Aurora PostgreSQL cluster with read-replicas, maintains strict

in-process package layer boundaries, and achieves a quoting computation latency of

p99 <= 45 ms.

Detailed Description

For engineering organizations with fewer than 30 developers, decomposing a line-of-business platform into dozens of microservices creates crippling operational friction. Developers spend more time managing Dockerfiles, Helm charts, service meshes, and cross-repo dependencies than shipping business value. A well-architected Monolith provides exceptional development velocity, effortless local debugging, zero-network in-process performance, and atomic ACID transaction simplicity. By decoupling compute from storage, the monolith scales horizontally across dozens of stateless application containers behind an Application Load Balancer while reading and writing to an Aurora PostgreSQL database cluster.

Public Consumer Quoting Traffic (4,200 req/sec)
                         │
                         ▼
[ AWS Application Load Balancer (ALB) ]
  └── Round-Robin Ingress across Stateless ECS Tasks
                         │
       ┌─────────────────┼─────────────────┐ (Horizontal Compute Scaling)
       ▼                 ▼                 ▼
[ Monolith Task 01 ]  [ Monolith Task 08 ]  [ Monolith Task 16 ]
  ├── 1. Web Layer: Spring Boot REST Controllers
  ├── 2. Core Service Layer: In-Process Rating Engine (< 12 ms)
  ├── 3. In-Memory Job Queue: High-Throughput Thread Pools
  └── 4. HikariCP Connection Pool (Max 25 Connections / Task)
                         │
        ┌────────────────┴────────────────┐
        ▼ (Mutating Writes)               ▼ (Analytical Reads: 85% Traffic)
[ Aurora PostgreSQL Primary ]     [ Aurora Read Replica Pool (2 Nodes) ]
  (3NF Relational Schema)           (Policy Search & Quoting Reports)

Criteria and weights

Alternatives rejected

Contracts and Invariants

Single Deployment Artifact Mandate [INV-MONO-01]
  The entire platform must build into a single deployable container artifact.
  Splitting services into separate deployment pipelines without Architecture Board sign-off is prohibited.

Stateless Compute Task Scaling [INV-MONO-02]
  Monolith compute containers must be completely stateless. Storing session state, uploaded files,
  or shared locks in local container memory or local disk across requests is strictly prohibited.

Connection Pool Concurrency Bounds [INV-MONO-03]
  Each monolith container task must bound its database connection pool (HikariCP) to maximum 25 connections.
  Unbounded connection pooling that threatens database exhaustion under autoscaling is barred.

Ownership and Handoffs

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against monolith architecture standards:

• Pragmatic Sizing: PASS. Unified monolith perfectly matches 24-developer organizational scale.
• Performance Execution: PASS. In-process actuarial rating engine easily satisfies sub-45ms p99 SLA.
• Horizontal Elasticity: PASS. Stateless compute tasks scale horizontally from 4 to 20 tasks under load.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-MONO-01: David O'Reilly to determine whether Redis should be introduced for centralized distributed HTTP session caching across ECS tasks or if stateless JWT bearer tokens suffice (Owner: David O'Reilly).

Next steps

1. DevOps team establishes the blue-green deployment pipeline for the unified ECS container task.
2. Database team provisions the Aurora PostgreSQL 16 cluster with 2 read-replicas.
3. Conduct staging load drill scaling ECS tasks from 4 to 16 instances under 4,200 req/sec to verify zero database connection exhaustion.

---

skill: monolith-architect

Auto Insurance Monolith Architecture — Fitness Self-Check [MONOARCH-FIT-001]

Summary

This fitness self-check evaluates the monolith architecture against three critical red-capable domain failure probes: anemic model, cross-context transaction, and duplicate language. All targeted probes pass by design construction. A self-check is supporting evidence, never the authoritative gate. Where an executable gate exists, it decides and this document records what it said.

Detailed Description

Residual Risk

• Increased deployment blast radius where a fatal error in the claims module requires deploying a hotfix to the entire unified application container. Accepted by Elena Rostova with automated blue-green rollback tooling.

Traceability

Verification

No validator was supplied, so no command was run.

Open Decisions

None.

Next steps

1. DevOps team incorporates ArchUnit boundary checks into master CI deployment verification.
2. Platform team configures Prometheus alerts monitoring ECS task CPU utilization and database connection pool waits.
3. Conduct quarterly architectural review assessing monolith codebase size and module coupling.