Services

mako implements the BDEW Marktkommunikation between the four German market roles — LF (Lieferant), NB (Netzbetreiber), MSB (Messstellenbetreiber) and BKV (Bilanzkreisverantwortlicher); see Party Roles.

mako consists of 17 independently deployable services, each a self-contained Docker image built on the mako-service SDK, with TOML configuration (env: and _FILE secrets), OIDC/JWT and API-key authentication, Cedar ABAC, OpenTelemetry, /health/live · /health/ready · /metrics, and an MCP server at /mcp (Streamable HTTP) on 15 of the 17 — all except outputd and agentd (the MCP host). just dev <service> runs one against dev/config/<service>.toml.

Service Map

graph TB
    ext["BDEW Counterparty<br/>(NB · LF · MSB · BKV)"]

    subgraph protocol ["Protocol & Market Data"]
        makod[":8080 makod<br/>EDIFACT runtime · 71 workflows<br/>AS4 · SlateDB · MCP"]
        marktd[":8180 marktd<br/>MaLo/MeLo/NeLo · contracts<br/>VersorgungsStatus · fan-out"]
        processd[":8580 processd<br/>Anmeldung STP ≥95%<br/>LF answers · §14a"]
    end

    subgraph nb_billing ["Invoice & Grid Billing (NB)"]
        invoicd[":8280 invoicd<br/>INVOIC 8-stage plausibility<br/>auto-settle/dispute"]
        netzbilanzd[":8680 netzbilanzd<br/>NNE/KA/MMM/MSB billing<br/>SettlementResult · CalculationTrace"]
        sperrd[":8780 sperrd<br/>Sperr-/Entsperrauftrag queue<br/>ORDERS 17115/17117 · IFTSTA 21039"]
    end

    subgraph data ["Energy Data & Observability"]
        edmd[":8380 edmd<br/>MSCONS · iMSys direct push<br/>validation · Ersatzwerte · virtual"]
        obsd[":8480 obsd<br/>process projections · KPI<br/>§7a Abs. 5 EnWG parity report"]
        mabis[":8880 mabis-syncd<br/>MaBiS Summenzeitreihe<br/>MSCONS 13003 · 10. Werktag · MCP"]
        einsd[":9180 einsd<br/>EEG/KWKG settlement<br/>10 schemes · §14 UStG Gutschrift"]
    end

    subgraph lf_billing ["Retail Billing (LF)"]
        productd[":9080 productd<br/>14 categories · §42 Stromkennzeichnung<br/>EPEX §41a · B2B Angebote"]
        billingd[":9280 billingd<br/>13 categories · XRechnung 3.0<br/>RLM demand · §54 exemption"]
        outputd[":9880 outputd<br/>Typst templates · ZUGFeRD carrier<br/>issued documents · delivery evidence"]
        accountingd[":9380 accountingd<br/>Massenkontokorrent<br/>SEPA FRST/RCUR · GLN ID · Aging · §288 BGB"]
    end

    subgraph b2c ["Contract & Customer (LF)"]
        vertragd[":9780 vertragd<br/>Kunden B2C+B2B · Rahmenverträge<br/>OIDC→MaLo · 17 MCP tools"]
        portald[":9480 portald<br/>customer portal read-model<br/>§41 self-service"]
    end

    agentd[":9580 agentd<br/>28 declarative manifests on agentplane<br/>journaled effects · strict replay<br/>human triage worklist · A2A cards<br/>OIDC · HMAC · 5 model backends"]

    ext -->|AS4 / REST| makod
    makod <-->|CloudEvents| marktd
    marktd -->|webhook fan-out| processd & invoicd & edmd & obsd & agentd
    makod -->|commands| netzbilanzd & invoicd
    mabis -->|MSCONS 13003 cmd| makod
    billingd -->|de.billing.rechnung.erstellt| accountingd
    billingd -->|render · pin hash| outputd
    vertragd -->|start-supply| processd
    portald -->|aggregates| billingd & accountingd & edmd & einsd & marktd

Protocol & Market Data

Invoice & Grid Billing

Energy Data & Observability

edmd's quality layer is metering's validation rules, run per register with an A/B/C/F grade, and its Ersatzwertbildung; its derived products are virtual meters (UTILTS Berechnungsformel, § 42b EnWG GGV), the § 40a Abs. 2 EnWG Verbrauchsschätzung, Resampling and Ablesesteuerung (INSRPT auto-order). meterstore tiers hot PostgreSQL against cold Apache Iceberg with cross-tier OLAP and a read-only Iceberg REST catalog, and every Cedar write action is role-gated to MSB/NB/admin.

Retail Billing (LF)

outputd's templates are content-addressed and append-only, and a publish is gated by proof; besides the invoice it renders the Textform kinds — Mahnung (§ 126b BGB) and Preisanpassung (§ 41 Abs. 5 EnWG) — and delivers over portal, e-mail, print spool and ERP with per-channel evidence.

B2C & AI

agentd's manifests are activated through [bundled_agents]; one event yields one journaled run per subscribing specialist, and since no manifest grants a mutating tool, a finding opens a triage row rather than suspending the run.

Shared foundation — the mako-service SDK

Every daemon is built on the mako-service crate. A service's main is a single line:

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    mako_service::run::<Billingd>().await   // Billingd: Daemon impl
}

run::<D>() owns the whole lifecycle. A Daemon implementation supplies only what is service-specific — the config type, the migrations, and a build() that assembles the domain router and spawns background workers:

flowchart TD
    start(["main → run::<D>"]) --> check{"--check?"}
    check -->|yes| probe["GET /health/ready<br/>exit 0/1"] --> done([exit])
    check -->|no| trace["init tracing"]
    trace --> cfg["load config<br/>TOML + env + _FILE"]
    cfg --> pool["connect tuned pool<br/>DatabaseConfig::connect(url, NAME)<br/>sets application_name"]
    pool --> migrate["D::migrate<br/>sqlx::migrate! + outbox::ensure_schema"]
    migrate --> build["D::build(cfg, ctx)<br/>domain Router + spawn workers on ctx.shutdown"]
    build --> infra["mount infra routes<br/>/health · /health/live · /health/ready · /metrics"]
    infra --> serve["serve with graceful drain<br/>SIGINT / SIGTERM"]
    serve -.->|readiness| ready["/health/ready = bounded SELECT 1 + D::ready"]

What every service gets for free from the runner:

Event-emitting services — accountingd, billingd, edmd, einsd, mabis-syncd, netzbilanzd, sperrd and vertragd — use the SDK's transactional outbox: each CloudEvent is written to event_outbox in the same transaction as the business change and drained by an OutboxWorker with retry and a status-column dead-letter queue. marktd keeps its own event_log outbox ahead of the durable fan-out, and invoicd retries ERP notifications from columns on invoic_receipts. Emission always goes through CloudEvent::new + post_ce_with_retry, signed as Standard Webhooks (webhook-signature).

Both outboxes wake their worker from an AFTER INSERT trigger's NOTIFY, which Postgres holds until commit; the 30 s poll is the fallback. cargo xtask check-outbox-notify holds trigger, channel and listener together.

makod alone keeps a bespoke main for its SlateDB event store and AS4 runtime; every other service, the stateless portald and agentd included, runs on mako_service::run.

Deployment

All services are available as multi-stage Docker images built with cargo-chef:

# Single all-in-one daemon (makod only)
docker pull ghcr.io/hupe1980/mako-makod:latest

# NB STP demo — UTILMD 55001 Lieferbeginn end-to-end
git clone https://github.com/hupe1980/mako
cd mako/demos/nb-stp
docker compose up

# EEG billing demo — solar plant registration + §21 EEG 2023 settlement
cd mako/demos/eeg-billing
docker compose up

# Order-to-cash demo — Tarif → Vertrag → Rechnung → Dokument → Offener Posten
cd mako/demos/o2c
docker compose up

See the Getting Started guide for the full deployment walkthrough.