BCS · the Branded Component System
Boundaries around systems, not objects.
Object orientation drew the encapsulation boundary around the object. The Branded Component System keeps encapsulation and moves the boundary outward, around the system: a system is a process that owns its private state and shares nothing, a component is data with no behaviour, and the only value that crosses a boundary is a branded identity — a fourteen-byte name — and messages about it.
The successor to Entity-Component-System, adapted to the BEAM: it gives up the shared component arrays of classic ECS for distribution and fault tolerance. Nine chapters, B0 to B8, with the Cache in depth.
How to read this course
the reading order- Start with B0. Three dives carry the whole idea — the one relocation, identity as a contract, the stack and the floor — and every other chapter elaborates one of them.
- Read down the stack. B1 and B2 lay the identity and the Elixir core; B3 is the bus; B4 and the Cache are the near-cache; B5 is the durable floor beneath it all. B6 composes the libraries into one umbrella, B7 is the course’s worked example written on top, and B8 is the production shape on Fly.
- Take each figure apart. A chapter is a landing and its dives; B2, the Cache and B7 group their dives into modules. Each dive is one idea with one figure: select a part to read its job.
- Trust what the tree proves. The course keeps one rule: a number the committed tree cannot prove does not appear. The contract’s own figures are the vectors
echo_dataasserts at boot, before either code path is trusted.
placement(USR0KHTOWnGLuC) → 234878118 native and pure agree parse(USR0NgWEfAEJfs) → {:ok, "USR", 320636799581945856} decode(USRzzzzzzzzzzz) → :error an overflow is refused, not wrapped
Course map
B0–B8 · the Cache in depth-
B0
Overview
The shortest path in: the one move the system makes, the contract that move leaves behind, and the shape of the stack the course builds.
-
B1
Ideas Behind
The conceptual floor: the system substrate, the identity contract read as architecture, and the step from ECS to BCS.
-
B2
The Elixir BCS Core
The law landed on OTP and ETS: a system as an OTP application, property stores, the CHAMP forest, archetypes composed by a fold, relations as systems, and the gate at the boundary.
-
B3
The Bus
EchoMQ, the bus the stack uses, where the BCS law meets the network: between systems, only branded identities and messages about them cross.
-
B4
EchoStore
The declared near-cache: L1 ETS tables in front of the shared L2 Valkey, one fill per herd, and coherence by mint time.
-
B4
The Cache, in depth
The near-cache built out: cache-aside at ETS speed, coherence by mint time, the single writer and its ring, and the lane that remembers.
-
B5
The Persistence Floor
Where state lives when the heap is gone: a single-writer engine on CubDB, a lazy reader at a snapshot, and a portable remote on Tigris.
-
B6
Putting It All Together
The four libraries as one dependency-ordered umbrella: one write all the way down, one read all the way up.
-
B7
Codemojex
The course’s worked example: a game in the Mastermind family, modelled as branded systems from its rooms and modes to fair-lane guesses, scoring and settlement, its economy, and its live surface.
-
B8
Production on Fly
The production shape on Fly: the release and its image, Valkey on its own Fly machine, the bus’s setup and monitoring, and the fly.toml beside a local stack.
Every chapter and module on this map is a page in the course. A chapter title opens its landing; a numbered line opens the module or dive itself.
The doors
related coursesRedis Patterns Applied
The Redis and Valkey patterns applied inside this architecture: sorted sets, atomic Lua moves, locks, and streams.
/echomqEchoMQ, In Depth
The bus the stack uses, taught as a course of its own — B3 in depth.
/echo-persistenceEcho Persistence
The durable floor beneath the volatile tiers, taught in full — B5 as a course of its own.
/echdechd — Echo on Encore
The platform course: the CAP trade segmented across this stack, each surface joined by one branded identity.
References
sources · relatedSources
- Leonard — Postmortem: Thief: The Dark Projectthe Dark Object System that relocated the boundary
- Hoare — Record Handling (ALGOL Bulletin 21, 1965)the tag inside the value the namespace descends from
- King — Announcing Snowflake (2010)the roughly-sortable id the contract hardens
- The Go Project — Share Memory By Communicatingownership behind a boundary, identities across it
- Erlang/OTP — the ets modulethe :private :ordered_set table a property store owns behind its boundary
- Steindorfer & Vinju — CHAMP (OOPSLA 2015)the persistent hash-array-mapped trie holding a store's values
- Valkey — Introduction to Streamsthe append-only log and consumer groups the Stream Tier is built on
- Lamport — Time, Clocks, and the Ordering of Eventsthe total order newer-wins carries in the name
- orbitinghail — Graft: lazy, partial, strongly consistent replicationthe page replication the persistence floor builds natively on the BEAM
- Helland — Life Beyond Distributed Transactions (CIDR 2007)durable entities a restarted system rehydrates by name
- Fly.io — Fly Machines (fast-launching VMs)the machine model the production chapter is written against
Related in this course
- B0.1 — The one relocationthe boundary leaves the object and surrounds the system
- B0.2 — Identity as a contracttyped by namespace, ordered by mint time, placed by hash, conformant across runtimes
- B1.3 — From ECS to BCSwhat the integer handle could not carry across a boundary
- B2.6 — Gates and acceleration at the boundarythe namespace gate that admits one kind and refuses the rest
- The Cache — Coherence by mint timenewer-wins as a comparison of two names
- B6.3 — One read, all the way upone branded id keying every tier, ETS to Tigris
- B7.1 — The game as branded systemsevery entity a branded id, the key in every layer