System Design: General Understanding

System Design is a process of defining components and their integrations, to build a large-scale system that meets the specific set of functional and non-functional requirements.

In real world, system building is a iterative process where we start with a reasonably good design, measure how it performs and improve the design in next iterations.

While for most of our engineers, System Design means interview

What is System Design Interview

so how is the Interview of System Design looks like?

The main goal of system design interview is in a limited time, figure out the requirement, and map them to the computational components, and how they communicate with each other.

How to treat System Design Interview

Basically the format of SDI can be different based on interviews’ style.

Some interviewer might be more interest on high level design, while others might choose one or more areas to focus on.

No matter how, the system requirements, constraints and bottlenecks should be well understood, to shape the direction for both interviewer and interviewee.

Goal of SDI

Final design is less important compare to the works, the ability you demonstrate during the process.

In this process, you can show your design skills, defend your choice, demonstrate your communications and respond to feedback in a constructive manner.

The primary goal of interviewer is to accurately access your ability.

The last thing interviewer want to know is to give an inconclusive evaluation because the session has gone poorly and there is no enough signal.

An effective System Design Interview should give a strong signal about person’s ability to collaborate, to work under the pressure, and to resolve the ambiguity constructively

Framework of SDI

Over-engineering is a real disease of many engineers as they ignore the tradeoffs.

there are other red flags like narrow mindedness or stubbornness.

To achieve an effective SDI, usually there is an 4-step framework to follow:

understand the problem (ask questions) -> propose high level design -> deep dive design -> wrap up

Understand the Problem / Ask Questions

Give out answer quickly without thinking gives no bonus.

Answering without thorough understanding of the requirement is a big red flag.

Assume your assumption is correct is another red flag.

Ask questions and think deeply to clarify the requirement and assumptions.

Usually the question you get during SDI is very vague, which mimicking the problems in real world, so your first job during interview, is to understand the requirements and constraints of the problems,

For example

• What’s the estimation of traffic
• What’s the capability of server etc.

Propose a high level design

This part it trying to reach the agreement with interviewer, to come up with a blueprint, ask for feedbacks just like teammates.

Then draw some box diagrams with key components.

An important thing is to clarify the traffic requirement and do back-of-envelop calculate to evaluate if the high level design could fit for the scale constraints.

Deep Dive the Design

This part is trying to design a concrete system to handle the problems you figured out at previous stages, and don’t forget: System Design only contains two part: component and their integration.

Just bear in mind, in System Design Interview, only focus on high-level stuff, low-level details will automatically come up

So the ability of abstraction is the most important ability in system design.

Also. you should have some initial idea about the areas to focus on based on feedback.

In this part you should also pay attention to time management, you must be able to show signals to interviewers, don’t get into unnecessary details, it cannot prove your ability in designing the scalable system.

so we should only design the critical components.

Evaluation / Wrap up

This is a great opportunity to show your critical thinking.

Error cases is interesting to discuss. also, how to handle next scale curve is another interesting topic.

If the system don’t have any trade-offs, then it’s not a realistic system, so when you complete the design phase, you have to figure out, what’s the trade-off you made.

During evaluation phase, we need to consider the 3 most important aspect of system

Reliability / Availability

Reliability is the most important thing we need to evaluate for our system, after all, reliability is the nature of softwares.

So during this phase, we need to evaluate

• how the system perform during down time, can it still provide service, so the system need to have
  • caching: which can provide records when the server is temporarily down
  • replication: redundancy can provide higher availability
• rate limiter can be a good way to increase system availability

Scalability

The scalability means extensibility, if the request increase a lot, how we can adjust current design?

So we need to adopt micro-service structure, so that we can scale up each component independently, without strong coupling with other components.

another factor need to take into consideration is hot key, if we cannot resolve the hotkey issue, then no matter how many more servers we can introduce, the issue is still not resolvable.

one more thoughts, actually the scalability is how common each component is , or how easy to replace each node.

Pub-sub system is always good for the scalability

Consistent

During distributed system, we usually compromise on strong consistency to achieve high performance and availability.

this aspect usually appears in our trade-off discussion haha.

General Suggestions

• don’t be unprepared for some typical interview questions
• don’t jump into solution without clarification
• you can not done until the interviewer says you are done