31–40 of 57 posts
The article should really mention CALM (Consistency as Logical Monotonicity)[1], it's much easier to understand and a more fundamental result than CAP. It is also much more applicable and enables people with little experience to build extremely robust distributed systems. Idempotence, CRDTs, WALs, Raft, they are all special cases of the CALM principle. [1]: https://arxiv.org/pdf/1901.01930
The article predates your paper by 6 years.
Earlier quoted context omitted.
*Between two distributed systems that don't share the same transactionality domain or are not logically monotone. It's easy to see that moving data from one row to another is doable in a clustered database, and could be interpreted as a message being delivered. The point is that you can get exactly once delivery, if your whole system is either idempotent, or you can treat the distributed system as one single unit tha…
> The point is that you can get exactly once delivery, if your whole system is either idempotent If you have exactly-once delivery, there's no difference between being idempotent or not. The only effect of idempotence is to ignore extra deliveries. If idempotence is a requirement, you don't have exactly-once delivery.
Exactly-once delivery semantics doesn't equal exactly-once physical messages.
Earlier quoted context omitted.
Yes but in practice this is not a problem because the bits that are impossible are so narrow that turning at-least-once into exactly-once is so easy it's a service offered by cloud vendors https://cloud.google.com/pubsub/docs/exactly-once-delivery
It's often not a problem because it's often easy to make a call idempotent. Consider the case where you attach an ID to every event and the subscriber stores data in postgres. You stick everything in a transaction, persist each event's ID, add a unique index to that column, handle failure, and bang, it's now idempotent.
One that is not mentioned here but that I like as a general principle is that you cannot have exactly once delivery. At most once or at least once are both possible, but you have to pick your failure poison and architect for it.
Yes but in practice this is not a problem because the bits that are impossible are so narrow that turning at-least-once into exactly-once is so easy it's a service offered by cloud vendors https://cloud.google.com/pubsub/docs/exactly-once-delivery
- you send a message
- you receive nothing back
- what now
There is no algorithm that lets you implement exactly-once delivery in the face of delivery instability. Either you don't resend and you implemented at-most-once, or you resend and you implemented at-least-once.
You might say, "but hey, the receiver of course sends acks or checkpoints; I'm not a total buffoon". Sure. Let's game that out:
- you send message 8
- you get an ack for message 7
- you receive no more acks
- what now
Every system you'll use that says it implements exactly-once implements send lots and has some mechanism to coalesce (i.e. make idempotent) duplicate messages.
A corollary: "in-memory is much bigger than you probably think it is."
I thought I knew what a large amount of RAM was, and then all the major clouds started offering 12TB VMs for SAP HANA.
edit: this seems like it's touched on very briefly with "Computers can do more than you think they can." but even that only talks about 24GB machines (admittedly in 2012, but still, I'm sure there were plenty of machines with 10x that amount of RAM back then)
Earlier quoted context omitted.
Apache Flink does provide end-to-end exactly-once guarantees when coupled with data sources and data sinks that participate in its checkpointing mechanism. See: - An Overview of End-to-End Exactly-Once Processing in Apache Flink (with Apache Kafka, too!) — https://flink.apache.org/2018/02/28/an-overview-of-end-to-en... - Flink's Fault Tolerance Guarantees — https://nightlies.apache.org/flink/flink-docs-release-1.20/d…
Exactly once processing != exactly once delivery
Earlier quoted context omitted.
Apache Flink does provide end-to-end exactly-once guarantees when coupled with data sources and data sinks that participate in its checkpointing mechanism. See: - An Overview of End-to-End Exactly-Once Processing in Apache Flink (with Apache Kafka, too!) — https://flink.apache.org/2018/02/28/an-overview-of-end-to-en... - Flink's Fault Tolerance Guarantees — https://nightlies.apache.org/flink/flink-docs-release-1.20/d…
Exactly once processing != exactly once delivery