Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Fault Tolerance

All the components - Load Balancers, Web Servers, Cache and Database should have multiple instances for improved availability. There should be robust monitoring and alerting systems on them.

All nodes can fail. Let's look at important failure cases.

Failure in Mapping Service

If Mapping Service fails (hardware failure, crash, software bug, network partition, slowness ...), it would directly impact the most time sensitive operation of this system, i.e., redirectURL(). To mitigate this, we should always run multiple Mapping Service nodes. It is s stateless service, so we can multiple nodes of the same service. We can use a coordination service, e.g., ZooKeeper, to track which nodes are alive (i.e. sending regular heartbeat to ZooKeeper), which are likely dead (i.e. not sending heartbeats for some time), which nodes should be taking requests.

Failure in Cache

Losing cache would also impact redirectURL() functionality. For example, let's say Redis Cache that is holding 10% of short URL -> long URL mappings goes does due to a faulty memory. Mapping Service will now have to access the database for each of these mappings. This makes requests much slower. Increased load on the database may even have cascading impact - database gets slower and slower, Mapping Services retry, making the database even busier - ultimately resulting in the database crash.

We have multiple mitigations.

a. Create read replicas for Redis Cache. Let's say for 1 leader, we put 2 read-only replicas. Writes are handled by the leader, and propagated to read replicas by transmitting a write log. Reads can be handled by all three. If the leader goes down for some reason, one of the read replicas can become the leader (after a leader selection process) and take over the responsibility as the leader. This would avoid the aforementioned scenario.

b. Mapping Service should have a mitigation strategy to avoid overloading the database. For example, exponential backoff before retrying, rate-limiting, and circuit-breaking.

Scalability - redirectURL()

Caching improves scalability on reads significantly. As the number of reads increases and pressures Shortening Service, we can increase caching capacity on both CDN and in the data center to serve more requests from caching.

Scalability - shortenURL()

As the number of write requests to shortenURL() increases, it might put too much pressure on the database, causing slowness, errors, or even crashes.

To avoid this, we can introduce a message queue to buffer the requests. Shortening Service would push a message in Message Queue, representing the request. Queue Worker would pull from the queue, creates the mapping in DB, and notifies the client the mapping is ready. The system can inform the client with long polling.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10