Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Since URLs are typically kept under 2000 chars with a maxim value of 2083 chars then we can argue that our best compression algorithm will
Request to get a shortened URL from an initial one of type POST. Response is a JSON object containing the shortened version and any metadata (if necessary) such as date and response time.
We have two different efficiency components for our database, both multi-layer. The choice of the database structure stands in what we value most, speed or memory efficiency. In the first case we can multi-layer the database based on the frequency of our URL thus maximising potential speedup. In our second design we layer the database on the commonality of the subphrases we encounter, which would be more efficient, but not more amortised efficient. We can choose to hybridise both.
Our main database will focus on minimising memory space. Suppose our layers are comprised of chunks of characters which are assigned a hash-value specifying the replacement character(s). This will be our main mode of translation
We can further extend with an intermediate database following a TLB - like pattern: we will have two different databases, one that matches upon parsing and a second dealing with the misses from the first, both acting as a intermediary cache storing most commonly used phrases.
Our program will differ from other URL shortening providers. Instead of the intuitional perspective of creating a unique ID for each URL submitted and storing that for a specific amount of time we can use a compression algorithm to specify a direct implication to the initial URL.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?