Hacker News new | ask | show | jobs
by mathias_10gen 5391 days ago
Its actually possible to be fully consistent if you include the "tension" documents when fetching the main docs.

For example, in the canonical transaction example of Alice giving Bob $5 you could insert a document in the transactions collection that says Alice gave Bob $5. When you go to fetch Alice's pending balance you fetch her current document, then you fetch all pending transactions than she is involved in. Same for Bob and all other users. Then each night, you pull that days transactions and apply them to each user and update an "as of" field to make sure no transaction can ever be applied twice.

Now you could argue that this isn't fully consistent because it is possible for Alice to simultaneously give $5 to both Bob and Charlie even if she only has $7 in her account. However she will then have a pending balance of $-3 so it immediately reflects her current situation. This is similar to the real world example of overdrawing you checking account. If you wanted to, you could void one or both of those transactions if you never want to allow a user to go negative.
1 comments
St-Clock 5391 days ago
The system you describe, recording events and replaying events to get the actual state of the system, usually assumes that you can only write one event at a time (writes need to be super cheap). If you can write multiple events in parallel, you won't have isolation and you may read tension documents that will be voided (in your example).

You could use optimistic concurrency control to ensure that only one tension document is written at a time while ensuring that your constraints are respected:

  current_id = atomic increment global state_id
  create tension document (but with active bit set to false)
  check constraints
  atomic:
    if global state_id = current_id
    set active bit to true
  if active bit is false:
    delete tension document and report error
This would provide isolation (you don't see tension documents that are not yet validated) and consistency (your balance is respected).

The atomic operation in RDBMS is usually implemented in one very simple and fast SQL UPDATE query. I believe mongo must provide something similar too.

Although my bank would allow me to overdraw from my checking account, I have a higher margin/tolerance than my brother, so they must perform some constraints check ;-)

link