Architecture decisions
These are the decisions that still matter when operating or extending the current Atlas stack.
One shared ALB instead of API Gateway
Atlas currently uses an internet-facing ALB as the single edge for the environment. The archive shows an earlier API Gateway plus VPC Link design, but the shipped implementation moved to the simpler and lower-cost shared ALB model.
Infrastructure-only repository scope
The repository owns shared infrastructure and runtime wiring, not application source. The events ingestion API and dashboard backend are expected to publish their own images from separate repositories.
Two roots, one module graph
terraform/staging and terraform/prod deliberately share the same root structure and shared modules. Environment differences should come from values, not from divergent infrastructure definitions.
Shared ECS cluster, separate services
Atlas keeps one shared ECS cluster for the current workloads, while isolating the events ingestion API, dashboard backend, and Kafka UI into separate ECS services and task definitions.
MSK with IAM + TLS
Kafka access is standardized on AWS MSK IAM authentication with TLS. Internal workloads use the internal bootstrap brokers, and the implementation also exposes a public IAM + TLS path where needed.
Secrets are provisioned by Terraform, values are populated operationally
Terraform creates the secret resources and placeholder document shape. Operators update the real values after apply so sensitive runtime configuration stays out of Git and out of long-lived Terraform diffs.
AWS-native observability first
The current roots rely on CloudWatch logs, Container Insights, CloudWatch alarms, SNS, and AWS Budgets rather than introducing a separate observability stack.
Use Notable changes when you need the short history of how Atlas arrived at the current shape.