This is by no means an exhaustive list, but should provide some insight as you're trying to backtrack through contract addresses on Etherscan. As upgradability issues become more frequent (security updates are rolling out in Ethereum libraries), the problem of systems design becomes part of planning, rather than ad-hoc. This is no normal Web2 systems design interview, however- the 'API' of your dapp is now immutable, given the nature of contracts deployed on a network.
Self-destruction means exactly what it sounds like- the contract is terminated and removed from the blockchain. So, when the term on a loan contract or the time period for a bidding contract ends, you can terminate the contract. When you do this, any future transactions related to the contract will fail and the funds sent to the destroyed contract will be lost. All references from other contracts to this one should be deleted or replaced, so that you don't have continuous funds sent to a dead contract.
This destruction actually results in negative gas, since the available memory of the EVM increases.
This is a design pattern for updating contracts, which has become an issue, as mentioned above. You have one contract that the users interact with (the proxy), and a second contract that is basically the logic/IP of that DApp, which we can simply swap out when the serious logic needs to be upgraded. But, how do you create a UI to interact with the proxy, which then cannot be a 1:1 mapping of the entire logic layer? Here is a great example from the OpenZeppelin docs:
This is most similar to the factory classes that you are familiar with from OOP- meaning you create a skeleton parent contract that has some state and functions, and all the children contracts derive the functions from that one and the parent can store the children contracts in its state.
The name registration pattern stores the mappings between contract names and addresses. This contract is literally just a mapping of all the contract addresses and names to create a centralized hub for all of your deployed contracts. Sometimes, it is the simplest designs that win.