Why we run one shared delivery layer
The reasoning behind ICDN, and what we got wrong the first time.
Every product we shipped solved caching on its own. HRMS cached at the application layer. Lever Today leaned on its host's edge. SmartDeliver did neither, and we found out during a rollout when a depot on a thin connection took nine seconds to load a route list.
The first attempt at fixing this was a shared library. It failed for the reason shared libraries usually fail: it moved the code into one place but left the decisions in five. Each product still chose its own invalidation strategy, and the moment two of them disagreed we had no way to reason about what was actually cached.
ICDN is the second attempt, and it moves the boundary rather than the code. Caching rules, invalidation and observability now live behind one delivery layer that every product talks to the same way. A product no longer decides how it is cached; it declares what its content is and how long it stays fresh.
What we would tell ourselves eighteen months ago: the cost of a shared layer is not building it, it is agreeing on the contract. We spent three weeks writing the invalidation semantics down before anyone wrote Go. That document has saved us more time than the code has.
