The core and periphery pattern

A system often has to do two jobs that pull in opposite directions. It has to guard something valuable and never leak it, and it has to keep changing to please users. When both share the same code and access, every change to the second endangers the first. The answer is to split the system into a small, rarely changed part that holds the valuable state, and a large, fast-moving part that holds nothing worth stealing.

A payment system has to store card numbers and use them to charge people, and it must never let those numbers escape. Around it runs a second job that has nothing to do with card safety and never stops moving: the checkout pages, the discount codes, the receipts, the integrations. This second job changes every week.

Put both jobs in one codebase with one set of access rights, and every change to a checkout page or a discount rule becomes a change to a system that can read card numbers. Any of those changes could accidentally write a card number to a log file or send it to an analytics service. The team cannot review every line at every release, because releases happen constantly and most are about receipts and coupons. The valuable data sits inside a large, fast-moving codebase where any part could reach the card numbers, and no review can be sure none does.

The fix is to make the code that touches card data as small as possible and keep everything else away from it. One small component reads and stores card numbers and does nothing else. The checkout pages, the discounts, and the receipts live outside it and never see a card number. They ask that component to do the sensitive work and get back only what they need, a yes or no, a masked number, a token.

The card industry's own standard is built on this move. PCI DSS, the security standard for handling payment cards, applies to every system that stores, processes, or transmits cardholder data. Those systems are what an assessment has to cover. Shrinking that set is what the standard calls scope reduction. Pull card handling into one small, isolated component, and only that component falls inside the assessment. The checkout pages and the marketing site sit outside it. A smaller sensitive part means a smaller thing to audit, to secure, and to review line by line.

This split has a name. The small, guarded part is the Core. It holds the valuable state, the card data. It enforces the invariants, the rules that must never break, for example that a full card number is never handed back. It is minimal, it changes rarely, and every line of it is reviewed with care. Everything else is the Periphery: the checkout, the receipts, the discounts, the integrations. The Periphery is where all the convenience and all the change live. It holds nothing critical, and it reaches the Core only through a narrow, fixed interface, with no special powers inside it. It is just a caller, asking for a charge and getting back an answer.

You already use a system built this way. An operating system splits itself into a kernel and the programs that run on top of it. The kernel is small and has total authority over the hardware, the memory, the disk, the network, the processor. A program you run, a browser, an editor, a game, has none of it. To write a file or send a packet, the program asks the kernel through a narrow, fixed set of calls, and the kernel decides whether to allow it. It cannot touch the hardware directly.

A card vault and an operating system look unrelated, but the shape is identical. Put the smallest possible amount of logic in the position of highest trust, and give it total control over the thing that matters. Everything else runs outside that position and works only through that narrow interface. The kernel is the Core. The programs are the Periphery.

This is the property that makes the whole split worth doing. Because the Core holds all the critical state and the Periphery holds none, you can replace the Periphery whenever you like. A redesigned checkout page is a change to the Periphery only. It does not touch the card vault, so it does not require re-auditing the card vault. Release a new checkout on Monday and a new receipt format on Friday, and the part that guards the card data has not changed at all.

Try it the other way around and it does not work. The Core is where the valuable state lives, so changing it means touching the card data and the rules that protect it, and every such change has to pass the highest level of review. The Periphery is cheap to replace because it holds nothing. The Core is expensive to change because it holds everything that matters.

You will design systems that hold something valuable, a set of keys, a balance, a store of personal data. Whenever you do, find the smallest piece of code that has to touch it and draw a hard line around it. Give it one job: hold the valuable thing and enforce the rules that guard it. Push everything else to the other side of the line, and let it in only through a narrow interface with no special powers. Whatever you leave outside, you can rebuild any time without touching the thing you were trying to protect.

Skip this section if you only want the principle. Decentralized finance adopted this split openly. Uniswap v2, an exchange that runs as code on Ethereum, splits into core and periphery contracts. The core contracts are deliberately minimal. They hold the pooled funds and enforce the one trading rule that must never break, the invariant that defines a fair swap. The periphery, mainly a contract called the Router, handles conveniences like routing a trade and checking prices. The Router holds no funds and no special privileges inside the core. It is just a caller, the same role the checkout plays against the card vault.

The ERC8009 standard has the same split, a minimal balance-proxy core and a replaceable Router periphery. There the division was forced by a real vulnerability rather than chosen up front, a story examined in depth in the clear signing module.