4 ms·

I knew I'd see this in the comments. Yes it is how banks work, but I hate how this comment usually plays (and I'm not accusing you of this) into "It's good enou

I knew I'd see this in the comments. Yes it is how banks work, but I hate how this comment usually plays (and I'm not accusing you of this) into "It's good enough for banks therefore it's good enough for us" arguments. Banks have a really special set of historical and regulatory availability constraints that most systems do not deal with, not to mention, time constraints across the globe. If your business process can handle lag via auditing and reconciliation processes then by all means adopt EC, but I'm not sure that plays out as much as engineers reach for the EC toolbox.

lojack 9y ago
> If your business process can handle lag via auditing and reconciliation processes then by all means adopt EC, but I'm not sure that plays out as much as engineers reach for the EC toolbox. Not sure I agree with that. I'd argue that there's very few (if any) businesses that are strictly consistent. Sure, there may be pieces where consistency is important, and eventual consistency isn't a silver bullet you can fire and forget, but its uncommon to see entire systems modeled in a strictly consistent manner. This past year I've built a number of apps to support both core products as well as internal initiatives, and I don't think a single one was strictly consistent. There were parts of the apps that needed consistency, but as a whole they were pretty much all eventually consistent. What's important is that you understand when strict consistency is necessary, and when it can be relaxed, and that you understand when your operations are eventually consistent and when they aren't.
- dijit 9y ago
  Your comment would only need minor rephrasing to be a defense of C++/C code for greenfield projects in 2017. "You can be smart about when to use it, if you're good you'll know when you need it"- I personally feel that this is a dangerous default.

lojack 9y ago

> If your business process can handle lag via auditing and reconciliation processes then by all means adopt EC, but I'm not sure that plays out as much as engineers reach for the EC toolbox. Not sure I agree with that. I'd argue that there's very few (if any) businesses that are strictly consistent. Sure, there may be pieces where consistency is important, and eventual consistency isn't a silver bullet you can fire and forget, but its uncommon to see entire systems modeled in a strictly consistent manner. This past year I've built a number of apps to support both core products as well as internal initiatives, and I don't think a single one was strictly consistent. There were parts of the apps that needed consistency, but as a whole they were pretty much all eventually consistent. What's important is that you understand when strict consistency is necessary, and when it can be relaxed, and that you understand when your operations are eventually consistent and when they aren't.

dijit 9y ago
Your comment would only need minor rephrasing to be a defense of C++/C code for greenfield projects in 2017. "You can be smart about when to use it, if you're good you'll know when you need it"- I personally feel that this is a dangerous default.