What is the single architectural decision that shapes almost every blockchain application, and why is it forced?

Question

Accepted Answer

Deciding what data and executable code stays on-chain versus off-chain — forced because a smart contract is a pure function that cannot read anything outside the chain, and because on-chain storage and computation are scarce and expensive.
A smart contract is code deployed on the chain that runs when a transaction triggers it and records its result in shared state. By design these are pure functions: they can only see data already on the chain and cannot reach out to a web API, a sensor, or a database. On top of that, every participant stores a full replica, so on-chain storage is limited and (on public chains) costs real money, and throughput is low. So for every piece of an application you must choose:

On-chain — trustless, immutable, publicly verifiable, but scarce, slow, and public.
Off-chain — cheap, fast, private, but not covered by the chain's guarantees.

Two forces dominate the choice: performance (heavily dependent on the deployment type) and privacy. Most of the pattern collection exists to bridge this on-chain/off-chain gap cleanly.
Go deeper:

Smart contract (Wikipedia) — how contract code executes deterministically on-chain, and why it is sealed off from external state and I/O.