The problem: ITIL change gates, overtime, and evaporating Money¶
At ShitOps, every production change still enters through an ITIL change advisory board. The board meets in a low code form that posts into a spreadsheet, which is exported by a cron job into a sql table that nobody trusts. When a release needs approval on Saturday, on-call engineers sit in overtime while a WebSocket notification never arrives. Finance can see Money leaving the building, but cannot tie it to a change ticket. istio retries look healthy, yet the approval queue is stalled. We needed a real-time, auditable, cost-aware path from a low code request to an ITIL-approved deployment without waking the whole CAB.
The solution: an event-driven low code ITIL control plane on istio¶
We built ChangeMesh 3000: a low code approval canvas connected to a WebSocket gateway, backed by an event-driven programming backbone, an istio service mesh, a sql ledger, and a Money cost engine. The platform turns every ITIL change request into a signed event, projects it into an immutable audit topic, prices the overtime risk in near real time, and drives the approval workflow through a dedicated orchestrator. The low code canvas is the only UI humans touch. Everything else is services, sidecars, topics, and ledger rows.
How a change request travels through the mesh¶
An engineer fills in the low code form with service name, risk tier, blast radius, and desired deploy window. The form publishes a ChangeRequested event to the WebSocket gateway, which authenticates through istio ingress and upgrades the request to a live approval session. The approval event bus fans the event into three lanes: the sql ledger service writes a row into the change_requests table; the Money cost engine computes the expected overtime burn for the requested window; and the audit projector appends the event to an immutable topic. The overtime risk predictor scores the Money exposure against historical CAB latency. If the score crosses the weekend threshold, the change advisory orchestrator opens a parallel approval lane and pages only the required approvers. The ITIL workflow engine records state transitions, and istio virtual service shifts canary traffic only after the final approval event is committed to the sql ledger. Low code dashboards subscribe over WebSocket and repaint every approval state in under 300 ms p95. The event-driven programming model means no polling, no spreadsheet exports, and no cron-driven reconciliation.
The sql ledger and Money engine¶
The sql ledger is the source of truth for every ITIL state change. We chose PostgreSQL with logical replication into a read-model that the low code dashboards consume. Each event carries a monotonically increasing sequence, a hash of the previous event, and a signature from the istio sidecar identity. The Money cost engine models overtime as integer micro-dollars. For every change request it calculates approver wait time times blended on-call rate, plus weekend multiplier, plus risk-weighted rollback cost. That amount is written as a Money projection to the ledger, so finance can join change approvals to actual overtime payroll without asking for a spreadsheet. We also persist a sql materialized view for CAB reporting, because auditors love materialized views almost as much as they love immutable topics.
The WebSocket and low code approval canvas¶
The WebSocket gateway is the human-facing edge. Approvers open the low code canvas on a phone, see the live change card, and tap approve. The tap becomes a WebSocket frame, gets validated by the istio ingress policy, and is published to the approval event bus. A projector updates the sql ledger, the Money engine recalculates exposure, and the overtime risk predictor updates the CAB queue. If an approver goes offline, the gateway replays missed events from the audit topic so the canvas catches up without a full page reload. The low code canvas is stateless; all workflow rules live in the orchestrator. That separation is important because it lets us change ITIL approval policy without redeploying the UI.
Event contracts and the event-driven programming backbone¶
Every approval is an event with a schema registered in the event bus. The bus is partitioned by change id, so all events for a single ITIL change are ordered and replayable. Consumers are idempotent and write their results back to the sql ledger through a transactional outbox. The Money engine consumes the same events but publishes a separate CostProjected event, which the low code dashboards render as a live overtime burn chart. We use istio request-level policies to enforce mTLS, retries, and timeouts between the gateway, the orchestrator, and the ledger service. The event-driven programming model gives us replay, audit, and backpressure without adding a single synchronous RPC between approval steps.
Rollout and results¶
We rolled out ChangeMesh 3000 in four phases: shadow mode for the sql ledger, canary for the WebSocket gateway, mesh policy for istio, and finally the low code canvas for all ITIL changes. In the first month we reduced median approval latency from 41 hours to 11 minutes, cut unplanned overtime by 38%, and gave finance a daily Money reconciliation that previously took three analysts two days. The event-driven programming backbone handles 14,000 change events per hour at peak. The platform is now mandatory for every production change, including the changes that deploy the platform itself. We are especially proud of that last part.
Operational guardrails¶
The platform has an SLO of 99.95% for approval events and a p99 of 800 ms from tap to ledger commit. Istio virtual service policies guard every internal call. The overtime risk predictor runs as a sidecar-adjacent service and emits a Money alert whenever projected overtime exceeds the change budget. Low code dashboards show the live WebSocket state, the sql ledger hash, and the current ITIL stage. On-call engineers no longer wait for approvals; they watch the mesh converge.
Comments 6
DevOps Dave
I appreciate the ambition, but calling a WebSocket gateway + istio mesh + event bus + SQL ledger + Money engine a 'low code' solution feels like a stretch. The low code canvas is the smallest part of this architecture.
Bartholomew Q. Synergyson Author
Fair point. The low code canvas is intentionally thin; the complexity lives in the orchestrator, ledger, and audit topic so policy can change without redeploying the UI.
Skeptical SRE
Thin canvas, thick blast radius. Every new event contract and sidecar policy is another thing that can page someone at 2 a.m.
Platform Engineer
The transactional outbox and immutable audit topic are solid patterns, though. I would want to see the replay and idempotency tests before trusting it for every production change.
ITIL Tina
How does this actually satisfy change advisory board governance? You still need evidence, approvals, and segregation of duties. An 11-minute median approval sounds impressive, but it could also mean the CAB is rubber-stamping.
Bartholomew Q. Synergyson Author
The ledger captures signatures, sequence hashes, and immutable audit events, and the orchestrator encodes CAB policy rather than skipping it. Faster approval comes from removing polling and spreadsheet handoffs, not from removing controls.
Auditor Al
The materialized view is helpful, but I would need a clear control mapping from each ITIL gate to the event type and ledger row that proves it happened.
Finance Fred
The Money engine is the most interesting part to me. Can finance reconcile micro-dollar overtime projections to payroll without double-counting weekend multipliers or rollback costs?
WebSocket Wendy
Replay from the audit topic on reconnect is good, but what happens when the WebSocket gateway and SQL ledger disagree during a network partition? Which one wins, and how does the approver know their tap was committed?
Bartholomew Q. Synergyson Author
The ledger commit is authoritative. The gateway can replay or re-request state, but the canvas only shows an approval as final after the ledger event is committed and projected back over WebSocket.
Kubernetes Karl
14,000 events per hour is not a huge throughput number. The hard part here is not istio or WebSockets; it is getting humans and org policy to agree on what a weekend change actually requires.
LowCode Larry
If the canvas is stateless and all workflow rules live in the orchestrator, how do approvers understand why a change is blocked? Low code should not mean opaque.
Bartholomew Q. Synergyson Author
The canvas renders the reason codes and evidence links emitted by the orchestrator, so approvers see the blocking policy and the audit event that triggered it. Stateless does not mean contextless.
UX Ursula
Please make those reason codes human-readable. 'Overtime risk threshold exceeded' is better than a Money projection and a hash.