In a software system that uses a blockchain as one component, what typically has to sit around the chain — and why can't the chain stand alone?
Around the blockchain (shared ledger, smart contracts, tokens) sit a key-management component, off-chain auxiliary databases — an internal store for private data and a separate store for big data — and an API layer toward the applications; the chain can't stand alone because its privacy and performance limits push most data off-chain.
* A blockchain application is mostly not on the blockchain: private and bulky data live off-chain, and key management guards the identities that sign everything. *
Within the larger system the blockchain's job is storing and sharing data and executing smart contracts (it may also carry tokens as currency or asset stand-ins). Its two structural limits shape everything around it: everything on-chain is readable by participants (privacy), and full replication keeps on-chain storage scarce and slow (performance). So a realistic architecture adds:
- An internal database for private data that must never be public.
- A separate big-data store (often a cloud service) for anything too large for blocks.
- An API layer between that data-storage layer and the applications — the same as in conventional systems.
- Key management as an essential component: every participant holds one or more private keys that sign their transactions. A stolen private key lets anyone forge transactions in the victim's name — spend their assets, invoke contracts as them — and the chain offers no recovery, so protecting keys is protecting identity.
Seen this way, the whole pattern collection is an answer to one architectural question: which of these boxes does each piece of data and logic belong in, and how do the boxes talk to each other safely?
Go deeper:
Introduction to dapps (ethereum.org) — what a production decentralised application actually looks like around its contracts: frontend, off-chain storage, and the on-chain backend.