Sunday, June 14, 2015

Hiredintech - How to Prepare System Design

Hiredintech - How to Prepare System DesignDesign a URL shortening service like bit.ly.How would you implement the Google search?
Design a client-server application which allows people to play chess with one another.

How would you store the relations in a social network like Facebook and implement a feature where one user receives notifications when their friends like the same things as they do?

the right strategy and knowledge.

focus on the right things while discussing a problem.

Problems:

Approach questions in a chaotic way and get ratholed, or

Lack solid understanding of how to properly design architectures that scale.

kick off by replacing chaos with a structured approach to system design

Hearing the problem to declaring it solved.

Designing Scalable Architectures

Step 1: Constraints and use cases, scope the system first

The very first thing you should do with any system design question is to clarify the system's constraints and to identify what use cases the system needs to satisfy.Spend a few minutes questioning your interviewer and agreeing on the scope of the system.

Step 2: Abstract design

Outline all the important components that your architecture will need.

draw a simple diagram of your ideas.

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.

Step 3: Understanding bottlenecks

Perhaps your system needs a load balancer and many machines behind it to handle the user requests. Or maybe the data is so huge that you need to distribute your database on multiple machines. What are some of the downsides that occur from doing that? Is the database too slow and does it need some in-memory caching?

trade-offs.

Vertical scaling

Horizontal scaling

Caching

Load balancing

Database replication

Database partitioning

Using NoSQL instead of scaling a relational database

Being asynchronous

HAProxy, nginx, memcached, Redis, Lucene, RabbitMQ, Munin, NodeJS.

Everything is a tradeoff

it all boils down to balancing between time to market, system complexity, cost of development, cost of maintenance, availability, and many other things.

Don't get defensive: 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.

You first build a high-level architecture by identifying the constraints and use cases, sketching up the major components and the relationships between them, and thinking about the system's bottlenecks.

You then apply the right scalability patterns that will take care of these bottlenecks in the context of the system's constraints.

TODO:

Vertical scaling, Horizontal scaling, Caching, Load balancing,

Database replication, Database partitioning, avoid single point of failure