The answer is only the first choice:
You should consider: "deploy" only 1 contract (or a set of related contracts) that holds the information of all the sellers and all the stuff they sell and all the transactions that happens between buyers and sellers.
To make things clear, let us speak about the "Sellers". Think about you have a database and you want to create tables. You will create a table for Sellers. You will never create a table for each Seller. Similarly, you will create a Smart Contract for your Sellers and store there information inside that Contract. You should not deploy a contract instance for each Seller! This is the main idea that answer your question.
Additionally, you should not think about a contract as exactly an object in OOP. As proposed by Ethereum, Solidity is a Contract-Oriented Programming Language. Check its name at: https://github.com/ethereum/solidity. So, your should not just adapt your OOP in solidity. As some concept are applicable (like inheritance) and the others should differ (like the way we design the communication between contracts).
Another consideration to be added. If you will go with your second or third proposed approach, you will need more significantly much more gas to operate your system. Note that the "gas" required to deploy a contract is much much more than the one needed to communicate with another existing contract. Additionally, the gas needed to interact with a different contract is much much more than the gas needed to do some internal operation within the same contract.
The last consideration that should come to your mind is the management overhead needed to manage the contracts. If you go with the second or third approach, you should think about how much headache you will have if you will need, for example, to change the secondary owner of the contract; For example, in case you set a secondary owner (could be also a multi-sig contract) that is managed by you and not by the end user. And that you will need to use in case the end user (the seller) lost his private key for example!
However, after putting in mind the mentioned points, you may decide to organize your logic in separate classes and libraries to ensure maintainability and ease upgrading. In such a case you may decide to have contracts for:
- People: To contain people information (because every buyer may sell something and therefore be a seller, this contract will save both Buyers & Sellers)
- Products: To save products information.
- Market: To maintain your logic (This smart contract could handle and process the purchases)
Actually, you can still save the data of People and Products in the same Market contract. But this may complicate the future updates of your system. But you can also maintain both People and Products data in the same smart contract.