Systems Design

Question 1

Vertical Scaling

Answer 1

Adding more power (CPU, RAM) to servers. Think vertical like turning up the volume.

Inherently limited (you can’t add CPU forever) and doesn’t offer redundancy, since if you have one server with a ton of RAM it’s still just one server and you’re SOL if it goes down.

Question 2

Horizontal Scaling

Answer 2

Adding more servers. Think horizontal like a row of servers all lined up.

This is the preferred approach for most large scale organizations, since it offers redundancy and unlimited scale. You can always add more servers.

Question 3

Load balancer

Answer 3

Evenly distributes incoming traffic amongst web servers

Question 4

Database Replication

Answer 4

A strategy to support failover and redundancy on the database level

• Primary/replica relationship amongst the databases
• Only the primary receives writes
• Replicas get copies from the primary and only support reads
• Most databases more reads than writes, so there are usually many replicas to one primary

Question 5

What happens if a primary database goes down?

Answer 5

You promote a replica to be the primary. That db will immediately start receiving writes. You will likely have some data loss from whatever the lag was between the old primary and replica (example, if the replica copies data from the primary every 10 minutes, then you will have lost that 10 mins of data and need to recover it)

To mitigate that at GitHub we used MySQL’s semi-synchronous replication. A primary does not acknowledge a transaction commit until the change is known to have shipped to one or more replicas. It provides a way to achieve lossless failovers: any change applied on the primary is either applied or waiting to be applied on one of the replicas.

Consistency comes with a cost: a risk to availability. Should no replica acknowledge receipt of changes, the primary will block and writes will stall. Fortunately, there is a timeout configuration, after which the primary can revert back to asynchronous replication mode, making writes available again.

We set our timeout at a reasonably low value: 500ms

Question 6

Cache

Answer 6

a temporary storage area that stores frequently accessed data in memory so subsequent calls can happen more quickly

Question 7

Describe githubs tech stack

Answer 7

MySQL databases, Redis and Aqueduct for queues, and Redis/Memcached for ephemeral caches.

Question 8

Memcache

Answer 8

In-memory, key-value store for caching. Designed for simplicity

Question 9

Redis

Answer 9

In-memory, key-value store for caching. More feature rich than memcache. Offers things like advanced data structures, pub/sub, replication, etc that Memcache does not

Question 10

Name 5 things to consider when caching?

Answer 10

• When to use caching. I.E. For data that’s read frequently but written infrequently
• When to expire the cache
• Consistency. Keeping the cache and data store in sync
• Mitigating Failures. You need multiple cache systems across different data centers so there’s no single point of failure
• Eviction. If the cache is full, what should you remove to make room for new things? Least Frequently Used is the most common strategy. Followed by First in First Out.

Question 11

What is stateful architecture?

Answer 11

When the users session data is stored on a particular server. So, the first time you visit you hit Server A so for every subsequent visit to take advantage of the cache you also have to be routed to Server A.

Like when you go to check in for a race and you have to go to the line designated for your last name. None of the other check in stations will have your information

Question 12

What is stateless architecture?

Answer 12

When HTTP requests for a given user can be sent to any server, because they all fetch the session data from a shared data store.

Instead of having to go to your check-in line in a race, you can go to whichever line is shortest, because all of the check-in booths or checking people in on an iPad.