Hacker News new | comments | show | ask | jobs | submit login

For financial transaction services I can recommend sharding first by customer, then by ledger. As a result, instead of enforcing double-entry book-keeping standards within a single database, do it at an application-specific middleware server layer to enforce only the guarantees you need.

As with all decisions, there are tradeoffs. For a little more up-front complexity and a tiny nominal performance hit, this allows maintenance, encryption, non-uniform storage paradigms to suit individual ledgers, rolling upgrades, storage location migration, and other cool stuff which is typically painful with traditional all-or-nothing RDBMS architectures.




Presumably you want a fairly strict consistency guarantee for whatever double-entry invariants you do have. Does that cause a lot of complexity when you kick it up to the middleware layer?


It depends what you mean by significant. SQL update becomes a two phase commit with double network connection setup, execute, teardown latency as a worst case. External auditing must be made. Sounds like hell.

A flip-side view is that, in many cases, if you really want to trust your data (not your database), then you want to be doing this stuff to a large extent anyway... which means that, basically, it's just enforcing good practices that should have already been present.

Complexity and per-TX latency increases, but for that you get maintainability and a great deal of flexibility. Nothing is free... take your pick!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: