[design] thinking process

A strong process is crucial to successfully solving system design questions.

4 steps:

• Scope the problem: Don't make assumptions; Ask questions; Understand the constraints and use cases.
• Sketch up an abstract design that illustrates the basic components of the system and the relationships between them.
• Think about the bottlenecks these components face when the system scales.
• Address these bottlenecks by using the fundamentals principles of scalable system design.

About design:

• Everything is a tradeoff
• there is no one optimal system design.
• staying up to date

At the interview

First of all, follow the System Design Process. You already know how to apply it, so we'll be brief. Don't skip steps, don't make assumptions, start broad and go deep when asked.

Second, keep in mind that system design questions serve as an idea exchange platform. Be prepared for discussions about tradeoffs, about pros and cons. Be prepared to give alternatives, to ask questions, to identify and solve bottlenecks, to go broad or deep depending on your interviewer's preferences.

Don't get defensive: whenever your interviewer challenges your architectural choices, acknowledge that rarely an idea is perfect, and outline the advantages and disadvantages of your choice. Be open to new constraints to pop up during the discussion and to adjust your architecture on the fly.

1. Use cases
2. Constraints (Math)
3. Abstract design

• Outline all the important components that your architecture will need.
• Sketch your main components and the connections between them. 
• If you do this, very quickly you will be able to get feedback if you are moving in the right direction.
• Of course, you must be able to justify the high-level design that you just drew.
• Make sure you sketch the important components and the connections between them.
• Justify your ideas in front of the interviewer and try to address every constraint and use case.

4. Understanding bottlenecks

• Needs to be scalable, in order for you to be able to improve it using some standard tools and techniques.
• It may be the case that the interviewer wants to direct the discussion in one particular direction.
• Then, maybe you won't need to address all the bottlenecks but rather talk in more depth about one particular area.
• In any case, you need to be able to identify the weak spots in a system and be able to resolve them.
• Remember, usually each solution is a trade-off of some kind. Changing something will worsen something else.
• However, the important thing is to be able to talk about these trade-offs, and to measure their impact on the system given the constraints and use cases defined.

5. Scaling your abstract design


Scale:

• Vertical scaling
• Horizontal scaling
• Caching / Sticky Session
• Load balancing
• Database replication
• Database partitioning

Divide and Conquer - The Scalability Technique

• This is the scalability technique. Everything is about partitioning out work. Deciding how to execute it. Applies to many things, from web tier, you have a lot of web servers that are more or less identically and independently and you grow them horizontally. That’s divide and conquer.
• This is the crux of database sharding. How do you partitions things out and communicate between the parts that you’ve subdivided. These are things you want to figure out early on because they influence how you grow.
• Simple and loose connections are really valuable.
• The dynamic nature of Python is a win here. No matter how bad your API is you can stub or modify or decorate your way out of a lot of problems.

Avoid Thundering herd problem

Same as design in RAFT, use random!