Architecture¶
This page is a living overview of the examplerep platform. Refine it as services are added and boundaries become clear.
High-level view¶
Retail energy platforms typically split work by business capability so teams can own lifecycles independently. The following areas are common targets for dedicated APIs or applications:
| Area | Examples of responsibility |
|---|---|
| Accounts & customers | Profiles, contacts, preferences, service locations. |
| Enrollment & sales | Plans, quotes, enrollments, consent, disclosures. |
| Billing & payments | Invoices, payments, adjustments, collections. |
| Usage & metering | Meter reads, interval usage, estimates. |
| Integrations | EDI, utility or market interfaces, file transfers. |
| Notifications | Email, SMS, templates, delivery preferences. |
Not every area needs its own service on day one; introduce new services when data ownership, scaling, or release cadence justify a separate deployable.
Cross-cutting concerns¶
| Concern | Typical approach |
|---|---|
| Identity | OIDC with JWTs; provider-agnostic client configuration (Keycloak reference). |
| APIs | REST with OpenAPI for HTTP services; gRPC where streaming or strict contracts help. |
| Observability | Health checks, metrics, structured logging, tracing in Kubernetes / OpenShift. |
| Configuration | Environment-specific config; secrets from external stores, never committed to git. |
Deployment target¶
Engineering standards assume OpenShift as the Kubernetes distribution target, with GitOps (Argo CD, Kustomize) for cluster and application state. Infrastructure automation outside that loop may live in iac- repositories.
Next steps¶
- Link to diagrams or ADRs when they exist.
- List production services with repository names and owners in a table.