Thinking Into The Future

You can find the full system design doc here - Feel free to use it as a template for when you are doing a system design at your job!

The system design tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

• Products are rarely shipped in isolation: You will almost always iterate on them in the future, extending them and adding new features.
• You should always take some time to think into the future for your project. The amount of time you take will vary a lot based on situation, but it generally plays out like this across company types:
  • Smaller companies and startups: Spend less time as goal is to ship, and it's unclear if the company will survive to even iterate.
  • Big Tech/FAANG: Spend a lot of time as these companies need to think long-term to maintain their massive market presence.
• When coming up with future iterations during your system design, order them by likelihood of doing and level of priority.
  • Spend more time thinking through the scenarios at the upper end of the list and incorporate them into your system design if they are very likely to be done in the next couple months.
  • Your goal is avoid a scenario where you need to extend your system shortly after it's launched, but it's so brittle and fragile that you would need to rewrite huge swaths of it to accommodate the new use-cases.
• However, this is a failure mode on the opposite extreme and that is being unreasonably forward thinking and over-engineering your system as a result. Making a protocol more generic and scalable almost always takes more time.
• When building systems or services, seriously think about the assumptions you are making.
  • Will the input this API takes in always be in this format and have certain fields?
  • Will this hard-coded if-statement start blocking valid control flows in the future?