Amazon Coding Question – Solved

10 Live
A service maintains a database with three string columns: Column Name | Description ------------|------------ user_id | The user ID of the user who created the URL short_url | The shortened URL actual_url | The actual URL to redirect to There are m users with ids from 0 to m - 1 and q requests for the short URLs. For each request i, report the actual URL and the number of requests processed for the user who created the short URL till the i-th request. Given an array of n strings, database, where the i-th row is represented by the string database[i] in the format "<user_id> <short_url> <actual_url>", and q queries represented by the array of strings, queries, for each requested short URL, report an array of strings of length 2 with the actual URL and the number of times a request is made using a short URL created by a particular user. Example Suppose there are m = 3 users, database = ["0 sdsf www.google.com", "1 juytf www.google.com", "0 opoit www.kaggle.com"], and requests = ["juytf", "sdsf", "opoit"]. Short URL | Actual URL | Created By | Count for User -----------|------------|------------|--------------- juytf | www.google.com | 1 | 1 sdsf | www.google.com | 0 | 1 opoit | www.kaggle.com | 0 | 2

Asked in: Amazon

Image of the Question

Question Image

All Testcases Passed βœ”



Passcode Image

Solution


#!/bin/python3

import math
import os
// ... rest of solution available after purchase

πŸ”’ Please login to view the solution

Explanation


```
To solve this problem effectively, begin by understanding the structure of the data and the nature of the requests being made. The system maintains a database where each entry maps a short URL to its actual URL and identifies the user who created it. You are also given a list of requests in the form of short URLs, and for each request, you are required to output two pieces of information: the actual URL that corresponds to the short URL, and the total number of times the user who created that short URL has had one of their short URLs requested so far.

The first thing to note is the role of each part of the input. The database is essentially a static list that associates each short URL with a user ID and an actual URL. The queries, on the other hand, represent dynamic user interactions and are to be processed sequentially. For each query, you need to look up the short URL, retrieve the actual URL and the creator (user ID), then update and return the count of how many times any short URL created by that user has been requested.

Start by considering how to organize your data. Since each request requires an efficient lookup of a short URL to its associated user ID and actual URL, it would be useful to preprocess the database into a more accessible form. One effective strategy would be to build a mapping from short URLs to a pair of values: the corresponding user ID and the actual URL. This would allow constant-time retrieval of the necessary information for each request.

Once you have this mapping, think about how to track the number of requests per user. Since the number of users is known to be m, and user IDs are from 0 to m-1, a fixed-size structure like an array indexed by user ID could serve well for maintaining the request counts. This allows for quick updates and easy access to the count for any user as you process each query.

When processing the list of queries, for each short URL in the queries list, the steps would be as follows: first, use the mapping to find the user ID and the actual URL corresponding to the short URL. Then, increment the counter for that user, since this counts as a request for one of their short URLs. Finally, construct the output for this request using the actual URL and the updated count for the user.

This approach ensures that each query is handled in constant time after the initial preprocessing. The preprocessing itself only takes linear time relative to the number of entries in the database. As a result, the total time complexity of the solution is linear in the size of the input, which is efficient and well-suited for large data sizes.

It’s also important to handle edge cases in your thought process. For example, if a query references a short URL that does not exist in the database, you should consider how that scenario should be handled. However, based on the problem description and examples, it seems all queries are valid, so you can assume every short URL in the query list has a corresponding entry in the database.

Another aspect to think about is the format of the input. Each line of the database is a string containing three space-separated components. You need to correctly parse these components to extract the user ID, short URL, and actual URL. Similarly, the output format must be consistent: a pair of strings for each query, one being the actual URL and the other being the request count converted to a string.

In summary, the key ideas involve preprocessing the database for fast lookup, maintaining a request count for each user, and iterating over the queries to assemble the required output. The solution is structured, efficient, and scalable due to its reliance on dictionaries or arrays for quick access and updates. As long as you handle the data parsing and updates carefully, you will be able to answer each request accurately and efficiently.
```


Related Questions