2014-03-24 2:47 GMT+01:00 Peter Gutmann <[1]pgut001@cs.auckland.ac.nz>:

   Their prime directive is that financial value can never be
   created or destroyed, so you can never have a situation in which a
   failure
   anywhere will result in one blob of financial value being recorded in
   two
   locations, or no locations.  Saying that you'll address this by rolling
   back
   transactions won't fly both because no standard database can handle the
   load
   they work at, and because the financial world isn't going to stop and
   wait
   while you perform a rollback.

   So how do they do that? If there's power failure on a specific box,
   what happens? Are all transactions synced to disk before commit, thus
   minimal rollbacks? A minimal rollback takes a very small margin of what
   would happen in case of power failure on a box. Maybe they have several
   boxes advocating a single transaction, so that expectible failures
   would never crash a system completely.
   I can imagine mitigating this by redundantly processing everything, in
   which case sequence must be kept somehow and so I can't imagine it
   being ridiculously fast. Maybe you mean the throughput is insane,
   because that'd make more sense given the multiple months of CPU being
   thrown at it. If you didn't then caching would just slow things down
   (most of the time).
   Finance should run better on SSDs, so I imagine this is an old story.
   Overall a bit confusing, and I'd love some more details! Like, why are
   they even using disks when fiber and RAM might be faster and similarly
   reliable?

References

   1. mailto:pgut001@cs.auckland.ac.nz