ADR-002: Service Modules Over Microservices

Status

Accepted

Date

2024-01-01

Context

The platform needs independent, deployable business capabilities. Options: 1. Monolith with internal modules 2. Microservices with per-service infrastructure 3. Service modules — independent codebases sharing infrastructure

Decision

Build service modules: independent codebases with their own Lambda functions, SQS queues, and CDK stacks, but sharing a VPC, RDS cluster, and AWS account.

Modules communicate through SNS events only. No direct imports or synchronous calls between modules.

Consequences

Positive

• Independent deployment per module (own CDK stack)
• Shared RDS cluster reduces operational overhead
• No service mesh, API gateway, or service discovery needed
• Teams can own multiple modules without managing separate runtimes
• Per-case database isolation provides strong data boundaries

Negative

• Shared RDS cluster is a scaling ceiling (mitigated by Aurora auto-scaling)
• Shared VPC means network-level blast radius isn't fully isolated
• Module-level failures don't have full infrastructure isolation

Risks

• Tight coupling could develop through shared database schemas
• RDS connection limits could be exhausted by too many concurrent modules
• Operational complexity grows with number of modules (mitigated by CDK patterns)

Sign In

Sign In

Please set a new password.

Set Password

Cancel

?

Ask the Architecture ×

Ask questions about Nextpoint architecture, patterns, rules, or any module. Powered by Claude Opus 4.6.

Ask