1. How to approach a system design Step 1: Outline use cases, constraints, and assumptionsGather requirements and scope the problem.

• Who is going to use it?
• How are they going to use it?
• How many users are there?
• What does the system do?
• What are the inputs and outputs of the system?
• How much data do we expect to handle?
• How many requests per second do we expect?
• What is the expected read to write ratio?
  

Step 2: Create a high level designOutline a high level design with all important components.

• Sketch the main components and connections
• Justify the ideas
  

Step 3: Design core componentsDive into details for each core component.
Step 4: Scale the designIdentify and address bottlenecks, given the constraints.  For example, do you need the following to address scalability issues?

• Load balancer
• Horizontal scaling
• Caching
• Database sharding
  

Discuss potential solutions and trade-offs.  Everything is a trade-off.  Address bottlenecks using principles of scalable system design.

2. System Design trade-offs2.1 Performance vs scalabilityA service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.
Another way to look at performance vs scalability:

• If you have a performance problem, your system is slow for a single user.
• If you have a scalability problem, your system is fast for a single user but slow under heavy load.
  

Source(s) and further reading

• A word on scalability
• Scalability, availability, stability, patterns
  

2.2 Latency vs throughputLatency is the time to perform some action or to produce some result.
Throughput is the number of such actions or results per unit of time.
Generally, you should aim for maximal throughput with acceptable latency.
Source(s) and further reading

• Understanding latency vs throughput
  

2.3 Availability vs consistencyIn a distributed computer system, you can only support two of the following guarantees:

• Consistency - Every read receives the most recent write or an error
• Availability - Every request receives a response, without guarantee that it contains the most recent version of the information
• Partition Tolerance - The system continues to operate despite arbitrary partitioning due to network failures
  

Networks aren't reliable, so you'll need to support partition tolerance.  You'll need to make a software tradeoff between consistency and availability.
CP - consistency and partition toleranceWaiting for a response from the partitioned node might result in a timeout error.  CP is a good choice if your business needs require atomic reads and writes.
AP - availability and partition toleranceResponses return the most recent version of the data available on a node, which might not be the latest.  Writes might take some time to propagate when the partition is resolved.
AP is a good choice if the business needs allow for eventual consistency or when the system needs to continue working despite external errors.
Source(s) and further reading

• CAP theorem revisited
• A plain english introduction to CAP theorem
• CAP FAQ
  

2.3.1 Consistency patternsWith multiple copies of the same data, we are faced with options on how to synchronize them so clients have a consistent view of the data.  Recall the definition of consistency from the CAP theorem - Every read receives the most recent write or an error.
#1 Weak consistencyAfter a write, reads may or may not see it.  A best effort approach is taken.
This approach is seen in systems such as memcached.  Weak consistency works well in real time use cases such as VoIP, video chat, and realtime multiplayer games.  For example, if you are on a phone call and lose reception for a few seconds, when you regain connection you do not hear what was spoken during connection loss.
#2 Eventual consistencyAfter a write, reads will eventually see it (typically within milliseconds).  Data is replicated asynchronously.
This approach is seen in systems such as DNS and email.  Eventual consistency works well in highly available systems.
#3 Strong consistencyAfter a write, reads will see it.  Data is replicated synchronously.
This approach is seen in file systems and RDBMSes.  Strong consistency works well in systems that need transactions.
Source(s) and further reading

• Transactions across data centers
  

2.3.2 Availability patternsThere are two main patterns to support high availability: fail-over and replication.
#1 Fail-overActive-passiveWith active-passive fail-over, heartbeats are sent between the active and the passive server on standby.  If the heartbeat is interrupted, the passive server takes over the active's IP address and resumes service.
The length of downtime is determined by whether the passive server is already running in 'hot' standby or whether it needs to start up from 'cold' standby.  Only the active server handles traffic.
Active-passive failover can also be referred to as master-slave failover.
Active-activeIn active-active, both servers are managing traffic, spreading the load between them.
If the servers are public-facing, the DNS would need to know about the public IPs of both servers.  If the servers are internal-facing, application logic would need to know about both servers.
Active-active failover can also be referred to as master-master failover.
Disadvantage(s): failover

• Fail-over adds more hardware and additional complexity.
• There is a potential for loss of data if the active system fails before any newly written data can be replicated to the passive.
  

#2 ReplicationMaster-slave and master-masterTO be discussed in detail later.