Backup of Design and Deployment

Design

We listed down the main design components required for our TinyURL system. Let’s discuss them one by one.

Components

Database

The choice of our system’s database mainly depends on the requirements defined at an earlier stage of the design. Some points concerning the database choice for our system are as follows:

• We established that our system would be read-heavy with billion of records.
• The stored records will have no relationships among themselves, other than linking the URL-creating user’s details.

We already have developed a sound understanding of the various database types and their associated properties. We will use NoSQL to store user details as well as the mapping of URLs. Based on the requirements mentioned above, we can use a NoSQL database, mainly because of the following reasons:

1. When a user accesses our system without logging in, our system does not save UserID. SQL databases do not allow skipping a column’s data, but the opposite is possible in NoSQL databases, hence schema-vise a NoSQL database is preferable.
2. Scaling a SQL database horizontally is a daunting process and contradicts our scalability requirements; we want to scale and automatically distribute our system’s data across multiple servers. For this requirement, a NoSQL database would best serve our purpose.

Out of all the available NoSQL database options, MongoDB aligns with our requirements, specifically because of the following reasons:

• MongoDB, being a single leader DB, provides a higher read throughput as we can either read from the leader replica or following replicas; the writes have to pass through the leader replica. Since our service is more read-intensive and less write-intensive, it suits our use case the best. Other NoSQL databases–Cassandra, Riak, DynamoDB-- need read-repair during the reading stage and hence provide slower reads to write performance.
• MongoDB ensures atomicity in concurrent transactions and avoids collisions by returning duplicate-key errors for record-duplication issues. The other leader-less NoSQL databases provide weaker atomicity upon concurrent writes.

Sequencer

We need a sequencer to generate the short link. We have already discussed it in detail, which would be a foundation for the following discussion.

There are some inherent issues with sticking to the original 64-bit base for this design problem: the generated short URL might have readability issues because of look-alike characters. As a solution, we can eliminate the look-alike elements from this base system before generating the unique IDs. We can shift to base-58, which provides these preferable characteristics, better suited for the visual appeal and readability of the generated short URLs.

Modifications to the sequencer:

1. The similar-looking characters such as 0 (zero), O (capital o), I (capital i), and l (lower

...