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)
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.