demo

Documentation

Overview

Coremetry demo — extended real-bank topology (v0.7.64).

The base generator (main.go) covers the retail hot path. This file widens the mesh into the surrounding bank — ~20 more services across lending, onboarding/compliance, payment rails, open banking, ATM, disputes, rewards and treasury — so the topology graph reads like an actual institution rather than a handful of nodes.

Per the bank's real stack, every new service persists to the Oracle core (db.system=oracle, peer.service="oracle") and communicates asynchronously over Kafka (peer.service="kafka"); only genuinely third-party calls (credit bureau, SWIFT network, card scheme, market data) leave the mesh as external HTTP. So Oracle + Kafka sit at the centre of the graph with heavy fan-in, exactly like production.

Everything self-registers in init() — extra services merge into the `services` map and extra scenarios append to the weighted driver list, so main.go stays untouched.

Coremetry demo — cross-trace Kafka span links (v0.8.335).

The cross-signal "Linked traces" pivot (v0.8.329-333) reads the span_links table, but until now the demo never emitted OTLP Span.Links, so the pivot had nothing real to show. This file gives it data the way a real Kafka instrumentation would: every producer span records itself into a per-topic ring, and consumer spans link back to RECENT producer spans from OTHER traces on the same topic — exactly the batch-consume shape (one poll processes messages whose producers live in earlier, separate traces) that makes span links exist as a concept.

The ring is deliberately process-global and survives across traces — that is the point: links cross trace boundaries. Memory is strictly bounded: 64 refs per topic, and the topic set is the small fixed set of kafka-pub hops in the scenario tables.

Coremetry demo: realistic retail-banking traffic generator that emits OTLP traces, logs, and metrics over HTTP to Coremetry.

The simulated domain is a retail-banking backend: balance inquiry, money transfer, card payment, bill pay, fraud check and account-statement flows. Multi-hop HTTP server/client spans chain the mobile/web channel → API gateway → core-banking services, and every persistence hop emits an Oracle DB client span (db.system = "oracle", Oracle-style SQL + PL/SQL, server.address like "corebank-scan.prod:1521"). Errors (~5-10%) cover insufficient funds, fraud blocks and ORA- style database faults.

Usage:

go run ./cmd/demo -endpoint http://localhost:14318 -rps 2.0

Coremetry demo — table-driven mesh extension (v0.8.326).

bank_extra.go widened the base mesh to ~45 services with hand-wired scenario functions. Hand-wiring stops scaling past that point: every new hop is ~10 lines of span plumbing and the topology only grows as fast as we can type. This file grows the mesh to ~75 services by expressing a scenario as DATA — a chainSpec is an ordered tree of hops (protocol, latency band, failure odds, children) and one generic builder walks it. Adding a service or a whole call chain is now a table edit, not a new function.

Four new banking domains: the mobile/web channel platform, the fraud-ML pipeline, modern payment rails (instant + SWIFT/ISO20022), and the internal platform layer. Chains deliberately root at or call EXISTING services (api-gateway, auth-service, ledger-service, fraud-service, forex-service, payments-orchestrator) and consume topics the old mesh publishes (payment.initiated, customer.onboarded), so the new graph CONNECTS to the old one instead of floating beside it.

Slice 2 grows the catalog to ~100 with three more domains — the batch/ETL & data platform (EOD orchestration, CDC, DWH loads, regulatory reporting), the open-banking/API ecosystem (TPP gateway, consent, quotas, webhooks, partner portal) and ops/infra-adjacent app services (GDPR erasure, PKI rotation, backups, chaos probes). Same connect-don't-float rule: the EOD batch consumes risk.eod (treasury-service), webhooks consume payment.settled (payments-orchestrator), consent checks ride auth-service, account reads land on the existing account-service + Oracle core, and the audit trail forwards into the existing audit-service.

Realism contract (docs/DEMO-REALISM.md): every hop's latency goes through dur(minMs,maxMs) and every failure through rollFail(failPct) — the shared load model — so the mesh saturates, spikes and fails in lockstep with the rest of the demo. Everything self-registers in init(); the 17 hand-wired scenarios stay untouched.

realism.go — traffic shape, saturation, and incident model (v0.8.x).

The base generator emits a believable banking mesh, but at a FLAT rate with FIXED per-hop error probabilities and UNIFORM latencies. Real production traffic doesn't look like that:

• it breathes with the business day (a diurnal curve: quiet at night, a mid-morning peak, a smaller early-evening bump);
• it has organic micro-spikes minute to minute;
• every so often something breaks — a dependency degrades, the DB contends, a GC storm hits, a noisy neighbour saturates a node — and for a few minutes the affected window shows ELEVATED latency AND error rates that then recover on their own.

This file is the single source of truth for that shape. It exposes a global `L` whose three hot-path factors are read lock-free:

L.latencyFactor()  multiplies every dur() — saturation stretches the
                   whole latency distribution at once, so the trace
                   waterfalls and the http.server.duration histogram
                   move TOGETHER (which is what makes the percentile
                   charts and the anomaly correlator light up).
L.rateFactor()     multiplies the driver's scenarios/sec — the demo
                   actually slows down at 03:00 and surges at 10:00.
L.errorBump()      extra failure probability folded into rollFail(),
                   so failures CLUSTER during incidents instead of
                   being sprinkled uniformly forever.

Keeping all three in one model is what ties metrics + traces + logs to the same underlying story rather than three independent random streams.