Smart contract programming has been largely written by developers with primarily a traditional web background. Tooling and perspective is often limited to a classic single-application mindset, not taking stock of the unique trade-offs of running on a global system.
While most smart contracts use cases today are written totally bespoke, effectively carving up the shared word computer into discrete fiefdoms, we the microcontract/interlock design pattern
Queries can run locally for free / gas-less
NB these diagrams are conceptual, and actual implementation may combine layers into a single smart contract As is becoming imncreasingly common, splitting state from behaviour encourages reuse, behaviour upgradability, &c. This pattern is not unlike a networked database in a traditional microservice architecture.
State^|vAccess Control^ ^| |v vClient A Client B
This Access Control
layer may communicate over subcalls using the same protocol (ERC-902), which may in turn depend on state provided by other third parties (e.g. read only access, principle of least access, &c).
+---------Database----------+| || State A || ^ || | || v || +----Access Control-----+ || | | || | [✓] ACL B <-----------------erc902----> Auth Server A (Read Only)| | | || | [✓] ACL B <-----------------erc902----> Auth Server B (Read Only)| | | || | [✓] ACL C (Stateless) | || | | || +-----------------------+ || |+---------------------------+