Architecture Overview
The ShipSolid Platform Engineering Lab demonstrates enterprise-grade cloud-native patterns through a nine-pillar monorepo structure. See also the Platform Overview for the C4-level view.
Design Principles
- Domain-oriented decomposition - Each pillar maps to a distinct operational concern
- Generated control planes - ownership, catalog entries, and baseline CI are derived from service metadata
- Golden paths - opinionated templates and contracts guide teams toward the platform standard
- Observability-first - services are expected to emit metrics, logs, and traces with standard labels
- Infrastructure as Code - platform and observability resources are intended to be Git-managed
- Explicit experimental boundaries - unfinished control planes stay isolated until ownership, security, and rollout paths are defined
Dependency Graph
a-governance (standards)
|
v
d-services (apps) ---> c-platform (infra) ---> Azure Cloud
| |
v v
e-delivery (CI/CD) f-observability (monitoring) ---> Grafana Cloud
| |
v v
i-tooling (SRE kit) k-docs (documentation)
|
v
h-aiops (experimental, not on the production control plane)
Key Patterns
Platform Engineering
- Service metadata in
component.yamldefines ownership, CI commands, deployment hints, and catalog registration - Generated governance artifacts turn that metadata into CODEOWNERS and Backstage catalog entries
- Copier templates scaffold new services with metadata and observability assets built in
- SRE toolkit automates onboarding, SLO management, and cost analysis
Observability-as-Code
- Grafana dashboards, alerts, and SLOs are managed via Terraform environment wrappers
- Schema validation and OPA policies enforce alert hygiene and promotion checks
- Service ownership and telemetry expectations are generated from
component.yamlintof-observability/generated/service-observability.json - Environment tfvars still provide the active Grafana routing and pack inputs; federated packs remain a draft pattern
Infrastructure Modules
- Composable Terraform modules for Azure (networking, compute, ingress)
- Workload roots with
vars/<env>.tfvars - Policy-as-code for security guardrails and compliance scans
Local graph
Linked from 5 notes
Faro / RUM Technical Design
**Applies to:** Angular 17+ SPAs **SDK versions:** `@grafana/faro-web-sdk ^2.
Observability Overview
The observability pillar combines Alloy collector examples with a Terraform-managed Grafana Cloud
The Pillar Model
The monorepo is organized into nine alphabetically-prefixed pillars, each representing a distinct
Platform Overview
The platform pillar is currently centered on Terraform workload roots under
01 — Platform Architecture
How the platform is built — views, planes, signals, and the decision record indexes.
Related notes
Signal Forge ADR-005: Separate collector configmaps per deployment mode
Keeps cloud and local Alloy collector configs in separate files rather than one conditional configmap, so each mode's exporters stay explicit and uncoupled.
Signal Forge ADR-003: Span metrics generated before tail sampling
Places the spanmetrics connector ahead of tail_sampling so RED metrics reflect all traffic instead of only the ~25% of traces that survive sampling.
Signal Forge ADR-002: SpanLink for async RabbitMQ propagation (not parent-child)
Uses a SpanLink, not a parent-child span relationship, to connect RabbitMQ consumer spans back to the producer span across async, retry-prone delivery.
Architecture Overview
Signal Forge's topology, service communication, trace propagation, and per-signal pipeline flow across local and Grafana Cloud deployment modes.