From 0dc3757514b33e408baa55fe9c2a1adf767e4b9a Mon Sep 17 00:00:00 2001 From: Nulo Date: Tue, 1 Aug 2023 18:31:49 -0300 Subject: [PATCH] CRDT: --- CRDT.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 CRDT.md diff --git a/CRDT.md b/CRDT.md new file mode 100644 index 0000000..8471f73 --- /dev/null +++ b/CRDT.md @@ -0,0 +1,12 @@ +Un CRDT es una estructura de datos que puede ser modificada y luego asincronicamente sincronizada sin conflictos (es un "Conflict-free replicated data type", tipos de datos replicados sin conflicto) ([Wikipedia](https://es.wikipedia.org/wiki/CRDT_(Tipos_de_datos_replicados_sin_conflicto)) + +- [You might not need a CRDT](https://driftingin.space/posts/you-might-not-need-a-crdt) + +## Performance + +- [I was wrong. CRDTs are the future](https://josephg.com/blog/crdts-are-the-future/) + - [5000x faster CRDTs: An adventure in optimization](https://josephg.com/blog/crdts-go-brrr/) (a.k.a. CRDTs go brrr) + + > That silly academic paper I read all those years ago says some CRDTs and OT algorithms are slow. And everyone believed the paper, because it was Published Science. But the paper was wrong. As I've shown, we can make CRDTs fast. We can make them crazy fast if we get creative with our implementation strategies. With the right approach, we can make CRDTs so fast that we can compete with the performance of native strings. The performance numbers in that paper weren't just wrong. They were "a billionaire guessing a banana costs $1000" kind of wrong. + +