At least for me, the system design questions in an interview used to seem quite amorphous and difficult to wrangle. They can take many forms. Some companies and interviewers care primarily about the devops components and block diagrams of how to keep your web service up and running under high load. Others care about information flow and message busses / asynchronicity. And still others want you to design OOP (object oriented programming) concepts and class inheritance models. Here, we'll break down each of these, as well as talk a bit about how to approach the abstract questions with a bit more clear mindedness.
First thing is to stay calm, and try to approach the problem like your everyday job. It can be difficult because these questions are designed to be contrived and fit into an hour interview slot. You want to understand the goals of the interviewer. What skills are they looking to test? Start by being curious. Ask clarifying questions. "What is the goal of this system?", "Do we anticipate a large increase in traffic?", "If so, will it be lots of downloading bandwidth, or lots of simultaneous open connections?". Be precise in your naming. Take an extra five seconds deciding on the name of variables, classes, blocks, and components to determine an accurate name. Don't "come back to it later". Clarity of thought is demonstrated by how you communicate, and the names of things are paramount in that communication. For example. "message bus" instead of "transfer", "key value cache instead of "database" (or whatever flavor you choose), "FourWheelVehical" instead of "Car" (when naming a parent class that is more general). Generally, being verbose in your names is better. I see many more mistakes in candidates trying to use one or two words, when a specific four word phrase would be more clear.
For this type of question, you're being asked to draw boxes and relationships to achieve the task. The simplest version of this question would take the form "design the twitter backend". You would start with a load balancer, web server, and database. Potentially adding a cache layer for the most popular tweets and news. After drawing this, the interviewer may probe to see the limits of your scaling knowledge. What components might need to be duplicated or broken out into more components if we started receiving 10,000 times more read requests? What about write requests (publishing tweets)? For writes, you can start discussing multiple databases, whether a leader and follower model, or sharding across geography or user hash. For reads, you may want a cache layer in front of the database that has faster lookup. Notation is key for block diagrams. Whatever system you use, be consistent, and communicate your assumptions. Vertical cylinders are databases, usually relational. Boxes tend to represent most other components. Puffy clouds can represent services such as external APIs. If you have multiple types of arrows, be sure to share your intent of dashed vs solid. Sometimes information flows in one direction but requests for information flows in the other. Push vs pull requests. There aren't hard and fast rules for how to notate this, but be clear and consistent and communicative.
Some systems design questions can be closer to code and OOP principles. Here you may draw out inheritance, or may even implement some actual code of a few key classes. Listing attributes of classes / database tables also fits into this category. Oftentimes, though, you will not have to execute the code so syntax errors won't count against you so heavily. These questions can be a bit tricky, and leave you guessing as to where the interviewer is trying to lead you. There are follow up questions that will prove the shortcomings of your design, and if you had anticipated the correct follow ups, those can be mititgated. This comes with experience, but can often be partly luck. Adapting to the new information is the key. A simple example of this is if the interviewer asks you to design a game of scrabble on a 10x10 board with 4 players and 8 tiles per player at the start. You might hardcode the size of the board, or make it a matrix. Then the interviewer says, it's actually a 100x100 or even three dimensional 10x10x10. This breaks your assumptions, and makes you redesign. Hopefully the rest of the design is robust enough to handle this change. Keeping your assumptions modular helps here.
Systems design questions take many forms, and it takes a lot of practice to prepare for all types. A few key principles apply across the board, and hopefully you saw some of that from above. Take a few sample problems, and design them from soup to nuts. Class diagrams, sql schemas, web services, devops, and block diagrams. Executing on every type of design of the same problem can give you deeper insight into how they all interact, and can build your adaptibility when you're faced with an out of the box question.