eventualconsistency   67

« earlier    

Distributed systems for fun and profit
Perhaps what we want is a system where we can write code that doesn't use expensive coordination, and yet returns a "usable" value. Instead of having a single truth, we will allow different replicas to diverge from each other - both to keep things efficient but also to tolerate partitions - and then try to find a way to deal with the divergence in some manner. Eventual consistency expresses this idea: that nodes can for some time diverge from each other, but that eventually they will agree on the value. Within the set of systems providing eventual consistency, there are two types of system designs: (1) Eventual consistency with probabilistic guarantees. (2) Eventual consistency with strong guarantees.
book  article  distributed  computing  crdt  eventualconsistency 
10 weeks ago by dlkinney
GitHub - ricardobcl/Dotted-Version-Vectors: Logical Clocks for Eventually Consistent Systems
Excellent write up. The DVV approach is basically to store the context for each value, so when a PUT comes in you know which sibling value against a key it is replacing.

"A false conflict occurs when a set of values contains values that should be discard, if the causality were correctly preserved, as they are related in a causal evolution chain and do not contain concurrent updates. VVs with CI don't have false conflicts like VVs with SI. However, they don't scale well. On the other hand, VV with SI scale, but don't have a good support for the identification of conflicting values."
VersionVectors  Replication  SystemDesign  EventualConsistency 
february 2019 by colin.jack
Spanning The Database World With Google
If relational databases had just worked at scale to begin with, the IT sector would be a whole lot more boring and we wouldn’t be having conversation a conversation with Andrew Fikes, the vice president and Engineering Fellow at search engine, application, and cloud computing giant Google who has been instrumental in the creation of many of its databases and datastores since joining the company in 2001.

Luckily for us, then, the database sector is just as interesting as it has always been because the applications that drive them keep changing, getting more complex and more demanding over time. Google’s Spanner is one of the most sophisticated, flexible, and scalable databases ever created, and it has spawned a clone called CockroachDB, which is also getting traction among enterprises and which is competing against Google’s Cloud Spanner service on its public cloud. There is also a certain amount of competition with the SQL database layers atop the Hadoop stack, various NoSQL datastores, and the ever-improving, enterprise-grade relational databases with columnar stores and in-memory processing.

It is an exciting time – still – in the database world.
Database  Google  spanner  bigtable  transactions  eventualConsistency  SQL 
january 2019 by euler
Goodbye Microservices: From 100s of problem children to 1 superstar | Hacker News
This is just not true. Google uses almost entirely immediately consistent databases and gRPC internally. Eventual consistency is hardly ever required for REST type calls even at massive scale.
gRPC has no queuing and the connection is held open until the call returns. All of Google's cloud databases are immediately consistent for most operations
EventualConsistency  microservice 
august 2018 by colin.jack
Conflict-free replicated data type - Wikipedia
In distributed computing, a conflict-free replicated data type (CRDT) is a data structure which can be replicated across multiple computers in a network, where the replicas can be updated independently and concurrently without coordination between the replicas, and where it is always mathematically possible to resolve inconsistencies which might result.
concurrency  data  distributed  datastructures  gossip  replication  eventualconsistency  riak  storage 
may 2018 by dlkinney
The Dangers of If Statements in Domain Logic
In a collaborative domain, with multiple actors operating on the same data in parallel, Dahan thinks we should start thinking about CQRS. When applying CQRS to a domain, his recommendation is to make it as simple as possible and design the solution so that a command that has been validated and enters the domain logic almost never fails. This means that when handling a command, we must for instance be prepared to lose in a race condition and still fulfil the overall business objectives. Often this leads to eventual consistency, but not the technical type with a read model that eventually becomes in sync with a write model; instead it’s from a business perspective. In this example, it’s about customers adding an item to their basket that is not for sale.

One solution to this is to use a long-running process that behind the scene removes the item not for sale from shopping baskets as they become inactive or time out. Eventually the item has been removed from all baskets and thus not sold anymore.
CQRS  EventualConsistency  DDD 
march 2017 by colin.jack
Perform Two Phase Commits — MongoDB Manual 3.0
Kinda like the outbox idea, but the message is whats saved and its applied asynchronously. Lot of work for developer considering this could be needed for many use cases in distributed systems especially when data is denormalized in multiple documents.
Messaging  Outbox  EventualConsistency  Mongodb  Architecture  NoSql 
december 2015 by colin.jack
The Netflix Tech Blog: NoSQL at Netflix
"There is little room for vertical scalability or single points of failure. And while it is not easy to re-architect your systems to not run join queries, or not rely on read-after-write consistency (hey, just cache the value in your app!), we have found ourselves braving the new frontier of NoSQL distributed databases."
CAP  EventualConsistency  NetFlix  Consistency  NoSql  AWS 
october 2015 by colin.jack
4 Ways to Handle Eventual Consistency on the UI
When the client receives confirmation the command completed, it can assume the new state of the read model. This is because you validated your commands before sending. The domain should also reject commands if they would fail or break a business rule. As a result the client can predict changes to the view. This approach requires careful thought to how you manage the version number. If you are building a web front end then javascript promises are a convenient structure to handle this process. This approach is, more time consuming, but results in a much smoother user experience.
EventualConsistency  UIDesign 
october 2015 by colin.jack

« earlier    

related tags

acid  acm  acync  akka  amazon  api  architecture  article  aws  ayb13  base  bigtable  book  cap  captheorem  cassandra  cloud  cloudpulse  computing  concurrency  consistency  cqrs  crdt  crdts  data  database  datastructure  datastructures  ddd  distributed-computing  distributed  distributeddatabase  distributedsystem  distributedsystems  dynamo  ec2  erlang  eventlog  eventsourcing  eventual-consistency  eventual  eventually  google  gossip  icecream  jimmybogard  keyvaluestore  kvd  loadbalance  martinfowler  messaging  microservice  microsoft  mochi  mongodb  netflix  nosql  outbox  programming  quorum  replication  research  rest  retry  riak  scalability  scaling  simpledb  soa  software-architecture  spanner  sql  statebox  storage  systemdesign  transactions  type:blog  udidahan  uidesign  versionvectors  via_delicious_20101217  video  web  webapps  workblog 

Copy this bookmark: