keeping doing great work (Y), page number 6, why are you returning short url directly from DB to client, it should be via DB=> APP server=> load balancer=> client
A few more extensions to this approach can be studied at ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-AVztRY77xxA.html which talks about how many characters you need for coming up with a short URL based on the #requests coming for this service. It also has some info about generating analytics info based on geography, #requests/sec etc
I think there is some minor flaw with the approach. Even if there exists a mapping between short URL and long URL, you'd still generate a unique hash because you don't want different users to own the same short link.
Hi! That’s a good point! In my design here, I didn’t take in account supporting unique shortURLs for individual users. If your app requires it, then yes you can generate the unique hash regardless at the expense of greater space usage.
Depends on how you want to cache the data. Typically server-side caches (such as Redis) will be on the API layer, while client caches can be build on the user's device.
How do you deal with persistence? Even in this simple system, it seems like you want to do something to make sure that the data in that MySQL database is recoverable -- especially if a lot of links to your tinyURL are being used all over the web.
Why does the web browser need a sever to generate short urls and tranlstae it back to long urls. Why is it so difficult for web browser to store long urls?
