What are the ideal use cases for weakly consistent systems?

Question

I have been reading about distributed databases and the like providing weak and strong consistency guarantees, but perhaps I am short on imagination - when would you want to use a weakly consistent system?

Most examples of real use-cases - services that share state across a distributed system, or read-write services accessible to users - seem to require strong read-write consistency.

What sort of situation is useful for a weakly consistent system?

see Why do 'some examples' and 'list of things' questions get closed? — gnat, Apr 07 '17 at 16:33
@gnat I don't see how this constitutes asking for an example or a list of things. I'm asking about when you would want to use a particular technology versus another. — Akshat Mahajan, Apr 07 '17 at 16:43
Weakly consistent systems are not very useful. Sometimes they are used simply to increase performance, and users are left to struggle with the occasional inconsistency. — Frank Hileman, Apr 07 '17 at 17:53

score 2 · Accepted Answer · answered Apr 07 '17 at 23:44

Concurrency

Weak consistency would only be OK for applications where an insert or update is does not rely on a previous select.

For example, consider this common workflow:

Read a record
Let a user edit it
Compute a new record based on the original record + the user's changes
Save the record

This sort of workflow would not work so well under weak consistency, because the record read in step #1 may be out of date, and saving the record may stomp on another change that is already in flight. If you change FIRST_NAME and someone else changes LAST_NAME, one of you may lose your changes.

On the other hand, if you are inserting records where 100% of the data come from an external source, weak consistency may be OK. Some examples:

An application that crawls the web and stores page information as it is discovered
An application that emits debug logs
A fire-and-forget audit logging mechanism

R/I

Weak consistency may not work so well if you have a lot of R/I. For example, if you are inserting a record that contains foreign keys, you can't be sure that the records with those foreign keys will still exist by the time your updates have propagated.

This would not be so much of an issue if your database doesn't allow deletes. For example, if you need to insert a Session record with a foreign key of UserID, and users are not allowed to be physically deleted, only disabled.

Identities and collisions

Any surrogate keys in a weakly consistent database would have to be globally unique; either a GUID or a compound key that contains the partitioning key. Otherwise, different nodes may end up inserting the same identity value and you will have a collision when the data propagate.

You should expand "R/I". – Derek Elkins left SE Apr 09 '17 at 05:11 — Derek Elkins left SE, Apr 09 '17 at 05:11

score 1 · Answer 2 · answered Apr 07 '17 at 22:42

The only use case that comes to mind is some system like Google that does fuzzy matching, has enormous performance requirements, is interested in data analysis in the aggregate, but isn't particularly concerned about losing a small number of individual data points here and there because they aren't going to matter.

Under those conditions, the loss of a small amount of data integrity is greatly outweighed by the enormous performance benefits you will receive by giving up on absolute durability of data.

What are the ideal use cases for weakly consistent systems?

2 Answers2