-2

I am putting together a system design for something similar to Tiny URL. It provides an API for mapping a URL to a short URL. Once created the short URL can be used to access the original URL. This system seems to need to be both available and consistent at the same time (which I know is not possible).

Available - If the system is not available, requests to a short URL will start failing - which defeats the purpose of having a short URL.

Consistent - If a system is not consistent - a newly created tiny URL may not be accessible for a while. Also if you update an existing URL to point elsewhere, the changes might take a while to propagate.

How then can we decide to choose one over the other? What factors should we consider?

Improve this question
7
  • Are the availability and consistency characteristics of one of the vast numbers of database systems out there (relational or otherwise) really not good enough for your use case? If so, please explain what your requirements are which mean you can't just (say) use DynamoDB.
    – Philip Kendall
    Aug 17, 2020 at 22:15
  • Actually my question is more about making this choice between the 2 characteristics in the context of tiny url. How do you go about picking one over the other (since you can't have both in the face of partitioning anyways).
    – darkmoonstone
    Aug 17, 2020 at 22:20
  • 3
    Well, assuming that you have to choose (and I'm not at all certain that you have to), which one is more important to you?
    – Robert Harvey
    Aug 17, 2020 at 22:20
  • To be honest - they both seem equally important - just looking for guidance on the thought process/factors to consider when deciding. I couldn't really find any good material on making this choice specifically so checking with the community here. Maybe like you said the answer is just pick what seems more important - choosing availability seems to make more sense to me but am really not sure.
    – darkmoonstone
    Aug 17, 2020 at 22:32
  • 1
    in this particular case you might choose as follows: for the distribution technology/schemes you're considering how long is the typical or alternatively the expected max latency before the url is consistently available at all replicas. Is that too long for you? If not, forget about it. In this particular case you're "write once": once the tiny url is created it is never changed. (Or very rarely.) Perhaps that latency to get initial consistency isn't a hurdle ...
    – davidbak
    Aug 17, 2020 at 22:57

2 Answers 2

Reset to default
3

It's a tradeoff that you evaluate against your use cases.

In this particular case you might choose as follows: Considering consistency, for the distribution technology/schemes you're considering how long is the typical or alternatively the expected max latency before the url is consistently available at all replicas. Is that too long for you? If not, forget about it.

In the "tiny url server" case you're "write once": Once the tiny url is created it is never changed. (Or very rarely.) Perhaps that latency to get initial consistency isn't a hurdle ... and if that's the case you can prioritize availability.

Improve this answer
1

The question boils down to: If there's a network partition (or just latency), would you rather serve old data, or not serve any data at all?

I think for a tiny URL service, it's pretty clear that possibly serving old data is better than not serving any data at all.

There's also the chance that the owner of a tiny URL might update it differently on each side of the partition. In that case, now you are randomly serving one of them to clients. The owner knows what they did and it's their own fault. It's still better than serving neither.

So, it appears that availability is more important than consistency for this application - just by using common sense.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.