Structure of the System Design

If you are working or interviewing for a senior software engineer role, then it’s crucial to build your expertise in system design. As a senior software engineer, you are expected to meticulously design and document your system design. Your goal during design should be to thoughtfully address as many scenarios as possible to minimize surprises during development and runtime. Effective system design significantly reduces development time and ensures the software meets stakeholder expectations.

Here’s the structure that you can use for the system design

Finalization of the Problem Statement

1. At the start, you might receive a brief summary of the problem. Start by defining the problem statement according to your comprehension of its context.
2. Begin by asking key stakeholders relevant questions to better understand the problem. This may involve discussions with interviewers, customers, program managers, or other stockholders. Inquire about features, usage scenarios, customer behavior, categories, numbers of customers/request, application traffic, technology stack, and plans for growth or scaling.
3. Based on the above understanding, refine your problem statement, as well as the scope and out-of-scope sections.
4. Clearly define nonfunctional requirements for the feature or application. Define SLI and SLO committing to the customers.
5. Determine the types of resources needed and approximate their quantity and cost.

High Level Design

1. Purpose initial architecture diagram where boxes represent the components and arrow represent the communication between the components. Define a short description of each component box.
2. Initially, concentrate on explaining the E2E scenario with use cases you have identified in the problem statement section. Consider the component boxes as black boxes and refrain from diving deeply into any single component at this stage.
3. Clearly define the customers to your application, inbound and outbound dependencies, data operations, data stores, etc.
4. Mentioned the assumption taken.
5. Get it reviewed from interviewer / stockholders for their feedback and address feedback.

Deep Dive

Deep dive from the customer interaction perspective

1. Define how customers will be interacting with the application.
2. Define clear APIs definitions, it’s request and request schema.
3. Discuss security constraints e.g. input validations, rate limiting, TLS, CORS, Idempotence, Authentication, logging.
4. Check if pagination, filtering, ordering and versioning is required.

Data Caching and Storage

1. What database to choose and why?
2. What is the schema of the data that need to be stored in the database?
3. How data fetching can be optimized with indexes?
4. Is data replication required? Why?
5. Is data partition required? Why?
6. Does encryption require for the data at wire and rest?
7. Does caching required? If yes, what strategy should be used?
8. Does operation need to be sync or message queue can be employed?

Individual components

1. Deep dive into the functionality of individual components (How this component work)
2. Evaluate if component is running in a thread Safe manner and there is no issue due to concurrency.
3. What is the input and output of each of these components.

Summary

1. Provide a brief summary of the solution.
2. Identify the components which are SPOF (Single point of failure) or bottleneck in scalability. Explain how this system can be improved.
3. How configuration for the system is stored? Do we need pull or push based configurations?
4. What is the authentication mechanism? Ensure you know about OAuth and JWT token working.
5. Check what are the error cases that need be handled
6. Observability: How health check for the system will be implemented, how operations will be audited, how events are being tracked, do we need to implement the distributed tracing, how logs will be stored and used for investigation of any issue, how monitoring will be implemented, and what dashboards need to be created.
7. Rollout and Rollback strategy