jonnify·art /art

A0 · Overview — The Art of BCS

The runtime is the platform.
The brand carries the state.

The Branded Component System taught the law; this course tests it in production. For a stateful, soft-real-time system run by one organization, the BEAM subsumes the four systems a production exchange is conventionally built around — a coordinator, a log broker, a message broker, and an orchestrator — and the branded identity carries the system’s state across every store and language.

The senior continuation of /bcs, taught from one working exchange platform. Every figure on every page is a committed gate transcript or a cited source. The claim is narrow on purpose: the regulated ledger, deep retention, and the observability sink stay outside the runtime by design.

The arithmetic of borrowed availability · a system on N third-party services, each available with probability a, has a ceiling of aN (derived; the cloud’s own published SLAs, AWS Compute SLA)
composite availability · nines seven nines · the target two nines · the credo’s floor 5 dependencies × 99.9% 99.50% ≈ 2.30 nines ≈ 43.7 h / year down from the dependencies alone
Third-party dependencies (N)
Per-service SLA (a) · the cloud’s own numbers
readout · Five dependencies at 99.9% each compose to 0.999⁵ ≈ 99.50% — about 2.30 nines, narrowly above the two-nines floor and far below the seven-nines target. The ceiling sits below the weakest single SLA, and it falls as the stack grows.
§1

The thesis — the runtime is the platform

art.preface.md · art.prelude.md

The BEAM — the virtual machine beneath Erlang and Elixir — was built at Ericsson from 1986 for very large numbers of concurrent, supervised, distributed, soft-real-time activities that must not stop. It provides, as language constructs, the properties the constellation supplies as infrastructure: lightweight processes for concurrency, supervision trees for self-healing, distributed Erlang for membership and discovery, bounded buffers for back-pressure, and hot code loading for change without downtime. The figure most often attached to that lineage is the AXD301 switch’s nine nines — which Armstrong’s own thesis reports with reservations, noting the long-term evidence was not collected systematically — so the course reads the nine-nines BEAM as a statement about design, not a guaranteed outcome.

The claim is narrow and measured, never anti-cloud zealotry: the patterns the course declines earn their keep at hyperscale and across many organizations. Three load-bearing claims carry it.

Claim one

The constellation is overpriced

Each member is a separate distributed system acquired to supply a property the runtime already has. You pay for it three times — in the dollars of running it, the latency of crossing it, and the availability it subtracts when it fails — to obtain what the BEAM provides for the cost of ordinary code.

paid in the currency that matters · availability

Claim two

Borrowed availability is proven to go down

Managed does not mean never-down, and an SLA is a credit schedule, not a guarantee. The arithmetic above is why, even in the months every piece meets its SLA, the composed product can sit below the line a real-time system needs.

and when the dependency is down · you wait

Claim three

Owning the runtime changes the ceiling

A soft-real-time system meets its deadlines predictably; the constellation’s failures are stalls on the path — a quorum re-electing, a consumer group rebalancing, a log partition unavailable mid-write. Owning the engine removes the third-party terms whose product capped you.

achievable availability becomes a function of your own design

The line the course does not cross: the regulated, double-entry record of settled money is PostgreSQL; deep retention and disaster recovery are object storage; observability terminates in a hosted sink. Each stays outside the runtime on purpose. What the course retires is the coordinator, log, broker, and orchestrator constellation — not the pieces where a property truly belongs outside.

§2

The arithmetic, derived

art.prelude.md · AWS Compute SLA

State the cloud’s case fairly first. The highest commitment AWS makes for compute is a monthly uptime of 99.99% for instances spread across availability zones, with a single instance committed to 99.5%, and no service offered at 100%. Availability composes by multiplication, so put the published numbers through aN — the same function the calculator above computes:

the composition, derived from the published SLAs (five independent dependencies)derived
five at three nines    0.999  ^ 5   = 0.99501   ← 99.50% · below the weakest single SLA
five at four nines     0.9999 ^ 5   = 0.99950   ← 99.95% · the cloud’s best, still under five nines
the credo’s target     seven nines       ≈ 3 s / year     ← unreachable while a third-party term remains
downtime at 99.50%     0.00499 * 8760 h        ≈ 43.7 h / year   ← from the dependencies alone

The ceiling sits below the weakest single SLA, and it falls as the stack grows. This is the arithmetic under the conviction the course is written from: chain enough borrowed availability and the product drops regardless of how good each piece is. The failure is not only that the nines are too few — it is that the missing time arrives as a spike on the hot path, where a matching engine can least absorb it, injected by a system that cannot be inspected while it happens.

§3

The constellation, subsumed

art.preface.md · art02.md

Each member of the constellation maps to a runtime primitive rather than an external service. Select one to read what it is for, and the runtime answer that subsumes it.

readout · Select a member above. Each card below is the static map; the four members the industry assembles as infrastructure are, for this class of system, properties the BEAM already holds.

Coordinator

→ distributed Erlang

ZooKeeper’s leader election, membership, and configuration — held by distributed Erlang, the single-writer principle, and the audited hash32 placement.

Log broker

→ Valkey streams

Kafka’s partitioned, replicated, retained log — below its envelope, per-instrument Valkey stream lanes, with three messaging shapes each in its own primitive.

Message broker

→ EchoMQ lanes

ActiveMQ / Artemis as a separate JVM daemon — the same work as a library on the database the platform already runs: fair lanes, at-least-once, pause, resume, depth.

Orchestrator

→ supervision + Fly + FLAME

Kubernetes’ scheduling, scaling, healing, discovery, rollout — supervision at the process, Fly machines as the grain, releases as rollout, FLAME for elastic compute.

What BCS adds — identity across boundaries

A runtime primitive coordinates within a runtime; a production system’s state lives in tables, on streams, in a Postgres ledger, in a cache, and in another language’s worker. The branded snowflake — a fourteen-byte identity, typed, time-ordered, self-placing, and identical across the canon — makes a fill matched by a process the same addressable entity in the ledger that records it, the stream that logs it, the cache that serves it, and the worker that prices it. The runtime gives the coordination; the brand gives the identity that makes the coordination span systems.

§4

The chapters

A0–A10 ⇆ the manuscript’s ten Parts

[RECONCILE]

§5

The doors — the sibling courses

course-to-course references
§6

References

sources · related

Sources

Related