Poco antes de terminar 2025, alcancé la cifra de 14 libros leídos, de los cuales 4 eran de desarrollo de software. Casi todos se centraban en arquitectura y diseño de alto nivel, así que buscaba algo más práctico a la hora de escribir código y con una perspectiva reciente.

Code That Fits In Your Head salió en 2021 y, como sabemos, nuestra industria cambia a pasos de gigante cada año. Este terminó siendo mi libro número 15 del año, las ideas que propone me parecieron tan interesantes que decidí que no podían quedarse solo en mi libreta de notas, así que ahí va este blog post.

🔗 Link al libro: https://www.goodreads.com/book/show/57345272-code-that-fits-in-your-head

📢 RECOMENDACIÓN PARA EL LECTOR: si esta leyendo esto, te sugiero que te leas los puntos 1,2,3 y 5 (como mucho). Si te gustan las ideas que contiene, prueba a leer el libro.

1. La realidad de nuestra industria (capítulos 1-2)

El libro comienza rompiendo mitos sobre qué es realmente el desarrollo de software.

• ⭐ Hacer software no es ni como construir una casa ni cuidar un jardín: Cuando la gente compara hacer software con construir una casa o cuidar un jardín, esas metáforas son muy lejanas a la realidad. La industria del desarrollo del software no se asemeja a ninguna disciplina en la ingeniería. Aún no tenemos metodologías replicables que puedan ofrecer resultados de manera consistente.

• ⭐ “A mí me funciona cuando hago las cosas así”: En el desarrollo de software actual, el ‘cada maestro tiene su librillo’ se ha convertido en una excusa para el subjetivismo. A diferencia de otras ingenierías, parecemos atrapados en un ciclo de experiencias individuales y contextos aislados. Este libro nace para buscar las leyes fundamentales que rigen nuestra disciplina, transformando la intuición personal en una ingeniería basada en principios (en lo que sea posible).

• El futuro ya está aquí, solo que no está distribuido de manera uniforme: Hay unas pocas empresas que están haciendo muy buen software y la mayoría, que siguen haciendo churros.

• 📝 Warnings como errores: Trata los warnings del linter o compilador como errores. Al principio frustra, pero mejora radicalmente la calidad de tu código y te hace mejor programador.

2. El código es para ser leído y mantenido (capítulo 3)

Uno de los pilares del libro es la legibilidad y sostenibilidad de tu código.

• Un ordenador no es como un cerebro. Con tu cerebro puedes tener como 7 cosas en contexto en la cabeza, la RAM de un ordenador puede tener miles.

• ⭐️ Sostenibilidad: El software engineering debería de hacer el proceso de desarrollo de software más uniforme. Debería de mantener a la organización que hay detrás. Algunos programadores nunca consideran si el código que están escribiendo tiene valor o no. Otros tienen dificultades viendo resultados cuantificables que no sean inmediatos. La sostenibilidad es un punto intermedio.

• ⭐ Optimiza para la lectura: Pasas más tiempo leyendo el código que escribiéndolo. Cuando escribes código, tienes todo el contexto en la cabeza. Piensa que quien lee tu código no lo tiene, tienes que hacer que su lectura sea lo más fácil y comprensible posible.

• ⭐ ¿Cómo escribo código legible?: No puedes confiar en tu intuición. Necesitas algo que puedas poner en práctica como el uso de heurísticas y checklists, eso es software engineering.

3. Más allá de hacer código que funciona (capítulo 4)

• ⭐️ La documentación debería de priorizar explicar el por qué una decisión se ha tomado. Antes que la decisión que se ha tomado.

• ⭐️ El objetivo no es escribir código rápido. El objetivo es crear software fácil de mantener.

• ⭐️ No utilices encapsulamiento con los DTOs: El rol de un DTO es capturar los datos que llegan a una estructurar de datos, o ayudarnos a transformar una estructuras de datos a output. No deberías de utilizarlo para ninguna otra cosa.

• Está muy bien el análisis de código estático pero los falsos positivos vienen con dicho territorio. Está bien deshabilitar o suprimir avisos específicos pero no lo hagas a la ligera. Al menos, documenta por qué lo has hecho y si puedes, obtén feedback respecto a la decisión

• ⭐️ Smoke tests: Aunque debas de estar a favor de crear tests automáticos, no deberías de olvidar los tests manuales. De vez en cuando, levanta el sistema y mira si echa fuego.

• 📝 Cuando el código de tus tests es muy grande, eso es un code smell.

4. ¿Es el TDD una ciencia? (capítulos 5 y 6)

• Al escribir tests, utilizamos el método Red - Green - Refactor:

  • 🔴 Red: escribe un test que falle

  • 🟢 Green: escribe el mínimo código posible para que el test pase

  • 🛠️ Refactor: mejora el código sin cambiar su comportamiento

• ¿Por qué TDD es lo más parecido que tenemos a una ciencia?

  • En el método científico, primero formulas una hipótesis en la forma de una predicción de un resultado no demostrado. Entonces realizas un experimento y mides el resultado. Finalmente, compruebas el resultado con la predicción que hiciste.

  • ¿No te recuerda a patrón Arrange - Act - Assert de los tests en programación?

• ⭐ Los tests te avisan cuando el sistema está funcionando como no queremos: Cuando haces modificaciones al código, ¿cómo sabes que no estas cambiando el comportamiento externo? Es muy difícil probar que todos los casos posibles funcionan igual. Pero es muy fácil probar que un caso ya no funciona bien.Si un test automático que has hecho deja de funcionar después de un cambio, ya sabes que has roto algo.

• Cuantos más tests añadas, mejor describes el sistema que estás probando. Es como ir añadiendo puntos de coordenadas en un mapa para determinar la ubicación del objetivo. Pero para que funcione, tienes que cambiar tu perspectiva con cada medida.

• ⭐ La encapsulación es la idea de que deberías poder interactuar con un objeto sin tener conocimiento de sus detalles de implementación. Esto te permite hacer cambios en la implementación, es decir, hacer refactor y pensar en el objeto de una forma abstracta.

  • ⭐ La noción más importante es que un objeto debería de garantizar que nunca va a estar en un estado inválido. Cuya responsabilidad no es de quien lo llama, sino del mismo objeto, pues es él mismo quien mejor sabe lo que significa que sea válido y cómo garantizarlo

• ️⭐ La ley de Postel: Cuando diseñas la interacción con un objeto, tienes que ser flexible con lo que recibes y conservador con lo que devuelves. Tienes:

  • Pre-condiciones: estas son las condiciones que el cliente debe de cumplir antes de interactuar con el objeto. Son sus obligaciones.

  • Post-condiciones: estas son las garantías que el objeto ofrece tras haber interactuado con él. Cuanto mejores sean, mejor.

5. La regla del 7 (capítulo 7)

• ⭐️ La regla del 7: Ante la premisa de que los humanos solo pueden tener 7 cosas en la cabeza, es decir, en contexto, deberíamos crear piezas de código que no hagan más de 7 cosas. Decimos 7, pero podrían ser 10 o el número que sea, siempre que se utilice el mismo número.

  • Así pues, podríamos acordar una complejidad ciclomática (cyclomatic complexity) de 7, cada vez que un cambio la exceda, lo rechazas.

• ⭐ Cuantas más lineas de código, peor es el código: Cuantas más líneas de código añadas, más líneas de código tendrán otras personas que ser capaces de leer y entender.

• ¿Qué es la cohesión en OOP?: Las cosas que cambian con la misma frecuencia deberían ir juntas. Las cosas que cambian con diferente frecuencia van separadas.

  • Piensa en los campos de una instancia de una clase. La mayor cohesión se consigue cuando todos los métodos de la clase utilizan todos los campos de la instancia

• Se presenta un ejemplo donde un metodo Validate convierte un dto en una entidad Reservation. El método Validate es quien utiliza todo el contexto del dto para checkear (más bien parsear) dicho objeto y si todo va bien, te devuelve un Reservation, una representación más fuerte de los mismos datos

6. Diseño de APIs y cómo evitar comentarios (capítulo 8)

• ⭐️ Diseña APIs de tal forma que sea difícil usarlas mal: No diseñes una navaja suiza.

• ⭐️ No digas algo con un comentario cuando lo puedes decir con el nombre de un método:

  • A ser posible, reemplaza un comentario con un método con un nombre que sea útil.

  • Al igual que los comentarios se vuelven obsoletos rápidamente, también lo hacen los nombres de los métodos. Cuando modifiques la implementación de un método, no olvides actualizar el nombre si es necesario.

• ⭐️ No digas algo con el nombre de un método cuando lo puedes decir con el tipado: Los nombres de los métodos son útiles pero no tienes que repetir lo que ya te dice el tipado del método.

  • • getReservationOrNull(): Reservation? ❌

      * `getReservation(): Reservation?` ✅
      

• ️⭐️ Hay casos en los que un buen nombre de un método no va a ser suficiente para comunicar toda la intención

  • Utiliza comentarios si quieres incluir por qué has decidido implementar el código de una forma en concreto.

  • Utiliza el mensaje del commit si quieres incluir las consideraciones que has tenido al realizar un cambio en el código.

  • Utiliza documentación o el README si quieres incluir cómo hacer set up del entorno de desarrollo o la misión que tiene dicho repositorio.

• 🚬 Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos puedan entender.

• ⭐️ Hay una forma de hacer código que es Command Query Separation (CQS) que se basa en mantener separados tus Comandos y tus Queries. Así, no devuelves datos en los métodos que tienen side effects y no causas side effects en tus métodos que devuelven datos.

7. Mejores commits y las pull requests (capítulo 9)

• ⭐️ Los mensajes de commit son el mejor sitio para explicar el porqué un cambio se ha hecho o por qué se ha hecho así.

  • Pon el mensaje del commit en imperativo.

  • Deja una línea en blanco y pon el resto en la descripción.

  • Regla 50/72: dejar el summary de 50 caracteres y cada línea de la descripción en 72 caracteres.

  • Ejemplo:

Introduce TimeOfDay struct

This makes the roles of the constructor parameters to MaitreD clearer.
A large part of the TimeOfDay type was autogenerated by Visual Studio

• La pregunta principal a la que tiene que contestar una pull request es esta: ¿me parecerá bien tener que mantener estos cambios?

• ⭐️ Rechaza pull requests grandes.

• ⭐️ Revisar una pull request entre autor y reviewer no es una buena práctica, porque el reviewer debería ser capaz de leer el código y entenderlo sin ayuda alguna.

• ⭐️ Se puede trabajar tanto en pair programming (2 personas) como en mob programming (3 o más). Esto hace que el código que escribís sea código con el que más de una persona del equipo está de acuerdo, y no reduce la productividad.

8. Versionado e integración (capítulo 10)

• ⭐️ Hazte un favor y leete la especificación el Semantic Versioning Specification: Si, entero. No tardas más de 5 minutos. En resumen, utiliza el esquema major.minor.patch.

  • Solo incrementa la major cuando introduzcas breaking changes.

  • Incrementa la minor para indicar que has introducido una nueva feature.

  • Incrementar la patch indica que has arreglado un bug.

• Si estás trabajando en una feature que toma mucho tiempo implementar, te verás tentado a desarrollarla en una feature branch.

  • No hagas eso, acabarás teniendo lo que se llama un merge hell 🔥

  • En vez de eso, esconde la feature tras un feature flag 🚩 e integra frecuentemente

9. Técnicas para arreglar bugs (capítulos 11-12)

• Hacer refactor del código en tests es más difícil que hacer refactor del código en producción. Con el código en producción sabes que tus tests cubren la lógica de negocio. Al cambiar los tests tienes que llevar más cuidado porque estas cambiando el comportamiento de tu sistema (sin tener tests que te protejan).

• ⭐️ Para entender por qué ocurre un problema hay diferentes técnicas:

  • Utiliza un pato de goma: explica el problema a un patito. Al explicarlo, quizás encuentras la solución. O mejor aún, pregunta en Stack Overflow.

  • Date un descanso, ve a por café o a por aire fresco. Muchas veces ese reseteo despeja la mente y vuelves con un enfoque fresco.

• En el desarrollo de software, “más tarde” significa nunca. Cuando aparece un bug, identificarlo debería ser tu prioridad. Para lo que estés haciendo y arréglalo.

• ⭐️ Utiliza la técnica de bisection para arreglar bugs:

  1. Encuentra una manera de detectar o reproducir el problema.

  2. Quita la mitad del código.

  3. Si el problema aún está presente, repite el paso 2

  4. Si el problema desaparece, restaura el código que has quitado.

• ⭐️ git bisect: Comando súper útil al que le das un rango (git bad y git good) e itera en los commits intermedios para localizar el error.

• ⭐️ Aprende y utiliza estas prácticas universales, ya que no puedes utilizar herramientas de debugging en el entorno de producción.

10. CQRS, funciones puras y buenos logs (capítulo 13)

• Cuanto más compones objetos mediante anidamiento, menor parte de esta composición cabe en tu cerebro al mismo tiempo.

  

• ⭐️ Sigue el principio de Command Query Separation. No dejes que tus queries tengan efectos secundarios. Si tu función es TrySave, lo cual indica que es un comando, no dejes que devuelva un boolean “por la cara”.

• ⭐️ Los métodos deterministas son aquellos en los que puedes calcular el resultado con solo saber el input (funciones puras).

  • Tienen propiedades muy deseadas: puedes abstraerte de lo que hace la función y solo preocuparte del resultado cuando leas el código.

  • ⭐️ Para funciones puras, la programación orientada a funciones es el rey.

• ⭐️ Mantén las queries no-deterministas y con efectos colaterales cerca de la frontera de tu sistema y haz uso de funciones puras para escribir lógica compleja.

• ⭐️ En cuanto a los logs:

  • Loguea los detalles de cada petición HTTP y su respuesta. También toda interacción con la base de datos, incluyendo los inputs y el resultado entero.

  • Loguea todas las funciones impuras pero nada más. Loguea todo aquello que no puedas reproducir: fechas, hora local, números aleatorios, lectura de ficheros, etc.vi

11. Las dailys, los descansos y escribir documentación (capítulo 14)

• Las dailys deberían ser: qué hice ayer, qué voy a hacer hoy y si tengo algún bloqueo.

• ⭐️ Trabaja en intervalos de tiempo delimitados como de 25 minutos con descansos de 5. No, no es exactamente el método pomodoro 🍅

  • Es importante que al tomarte estos descansos te levantes, des una vuelta si puedes o lo que sea

  • Las ideas o los eureka! Suelen pasar cuando estas haciendo deporte, corriendo o fregando los platos. No suelen ocurrir delante de la pantalla, sino cuando estás de pie

• ⭐️ Las reuniones no escalan, la documentación sí: En vez de poner una reunión cada vez que tengas que transferir conocimiento, escríbelo en un documento.

• El autor recomienda actualizar las dependencias regularmente, y así evitar actualizaciones grandes que tengan muchos breaking changes.

• Ley de Conway: cualquier organización que diseñe un sistema producirá inevitablemente un diseño que es copia de la estructura de comunicación de la organización.

12. Seguridad y property-based testing (capítulo 15)

• ⭐️ La seguridad en el software es como los seguros: no quieres pagar por uno hasta que te arrepientes de no tenerlo.

• Usa el acrónimo STRIDE como checklist: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service y Elevation of privilege.

• ⭐️ Property-based testing: testear campos por sus propiedades y no por valores concretos.

  • Si quieres incluir un test donde se pruebe con un valor negativo, ¿por qué utilizar el valor -1 en concreto?

  • ¿Qué pasaría si hubiese un framework que pudiese producir números negativos arbitrarios?

  • Eso es el property-based testing (e.g: FsCheck lib)

• ⭐ Behavioural Code Analysis: extrae información de Git para identificar patrones y problemas visibles solo con el transcurso del tiempo.

13. Organización de directorios en un proyecto (capítulo 16)

• ⭐️ ¿Cómo debería organizar los ficheros?

  • ➡️ Simplemente pon todos los ficheros en una carpeta.

  • Utiliza subcarpetas sencillamente para organizar el código

  • Los sistemas de ficheros son jerarquías (árboles) donde cada nodo solo puede tener un padre. Si pones algo en Controllers, no puede estar a la vez en Calendar.

• Si quieres encontrar ficheros, utiliza las funcionalidades de navegación de tu IDE.

Conclusión personal

No espero que este sea el post más entretenido que he escrito jamás, es más, ¡espero que nadie esté perdiendo el tiempo leyendo esto! Aunque aún me falta mucha experiencia por ganar en el desarrollo del software, hay ideas en este libro que me han cautivado por completo:

• El código como documento: Enfocarlo todo a una buena lectura tiene todo el sentido del mundo. Al fin y al cabo, el código es un documento que alguien va a leer y debe entender qué está pasando sin esfuerzo.

• La regla de las 7 cosas: Esta limitación cognitiva me parece una de las lecciones más potentes. Resuena mucho con lo que se enseña en otras áreas, por ejemplo, en bibliografía sobre cómo mejorar presentaciones, se recomienda no mostrar más de 4 elementos en pantalla para no saturar a la audiencia. En el código, igual.

• El Property-based testing: había escuchado sobre este pero nunca lo he visto en los proyectos en los que he trabajado. Tengo ganas de probarlo en algún repo que tenga por ahí.

Las ideas de Mark Seemann resuenan con mi manera de entender el software y creo que de ahí nace mi entusiasmo por este libro. Si algo de esto te ha hecho clic, te invito a que le des una oportunidad a la lectura completa.

Si me quieres comentar cualquier cosa o conectar conmigo: https://www.linkedin.com/in/juanjorequena/

Lo primero que debemos aclarar es que ACID no son propiedades de la base de datos en sí, sino de las transacciones que esta gestiona. Una transacción en una base de datos es una secuencia de operaciones que podemos tratar como una sola unidad indivisible. Pues bien, las transacciones ACID van a cumplir con las siguientes propiedades:

🟣Atomicidad (atomicity)

Cuando se ejecuta una transacción, esta va a ser realizada por completo. Si no es ejecutada por completo por algún problema, entonces será rechazada y revertida. Por lo tanto, si tenemos que una operación dentro de nuestra transacción falla, cada operación realizada va a ser revertida. Todo o nada.

➡️ Imagina que estás reservando un vuelo. Esta operación consisten en dos pasos:

1. Crear la reserva del vuelo.

2. Restar -1 asiento al número de asientos disponibles.

BEGIN;
  INSERT INTO bookings (flight_id, passenger_id, seat) VALUES ('IB123', 42, '12A');
  UPDATE flights SET available_seats = available_seats - 1 WHERE flight_id = 'IB123';
COMMIT;

La atomicidad asegura que o se ejecutan ambas operaciones o que ninguna lo hace. Si el sistema se cae justo después de crear la reserva pero antes de reducir el número de asientos disponibles, la base de datos revertirá la transacción entera.

🔵Consistencia (consistency)

Las transacciones transforman el conjunto de datos de un estado consistente a otro, garantizando que cuando se complete, se cumplan todas las restricciones definidas en el sistema.

➡️ Por ejemplo, digamos que tenemos una regla en nuestra base de datos para que el número de asientos disponibles en un vuelo nunca sea negativo:

CREATE TABLE flights (
    flight_id TEXT PRIMARY KEY,
    available_seats INT CHECK (available_seats >= 0)
);

Si la transacción hiciese que el número de asientos disponibles fuese negativo, la base de datos rechazaría la transacción completa.

🟢Aislamiento (isolation)

Las transacciones pueden ejecutarse en paralelo sin afectar la una a la otra. Es decir, una transacción no puede acceder a los cambios intermedios de otra mientras se ejecuta.

La mayoría de bases de datos permiten 4 niveles diferentes de aislamiento:

• READ UNCOMMITED: pueden ver cambios de otras transacciones que aún no han hecho commit (se usa raras veces).

• READ COMMITED: solo pueden ver cambios de transacciones commiteadas (por defecto en PostgreSQL).

• REPEATABLE READ: si lees el mismo dato varias veces, aunque otra transacción haga un cambio y commit, seguirá leyendo el mismo dato (por defecto en MySQL).

• SERIALIZABLE: provee del aislamiento más fuerte, las transacciones se ejecutan una tras otra en orden.

➡️ En nuestro ejemplo de reservas de vuelos, supongamos que solo queda un asiento disponible para el vuelo IB123.

Con un nivel de aislamiento READ COMMITTED, podría ocurrir que dos transacciones intenten reservar ese asiento al mismo tiempo. Ambas leen que el asiento está disponible. La primera transacción termina primero y hace commit, reduciendo el número de asientos disponibles a 0.

Al hacer commit, la segunda transacción también disminuye el contador de asientos a 0, provocando un overbooking: el mismo asiento se ha vendido dos veces.

Si en su lugar usamos un aislamiento SERIALIZABLE, la base de datos evita automáticamente este conflicto: aborta una de las transacciones que interfiere con la otra. La transacción abortada puede ser reintentada de manera segura, asegurando que nunca se reserve más de un asiento de los disponibles.

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- o REPEATABLE READ
-- o SERIALIZABLE
COMMIT;

Esto no significa que sea la mejor solución para este caso, ya que habilitar el modo SERIALIZABLE puede afectar el rendimiento. Sin embargo, en este caso sí garantizaría que la operación funcione de forma segura.

🟠Durabilidad (durability)

Cuando una transacción es completada, los datos deben persistir en el sistema aunque haya un fallo en el servidor. Los datos nunca pueden perderse.

➡️ En nuestro sistema de reserva de vuelos, si la transacción se completa, el asiento queda reservado incluso si el servidor se apaga después. La confirmación del COMMIT asegura que la reserva esté escrita en disco.

📢Por qué ACID sigue importando

Al elegir qué base de datos utilizar para tu sistema, es importante valorar si priorizamos más la disponibilidad o la consistencia. Como vimos en ¿Qué es el teorema CAP?, en sistemas distribuidos normalmente hay que priorizar una propiedad sobre la otra, al menos en cierta parte del sistema. Por ello, elegir una base de datos que cumpla con las propiedades ACID es una excelente opción cuando la consistencia es vital (tal como se define en el teorema CAP).

Considera los siguientes escenarios:

• Transacciones financieras: aquí es imprescindible contar con ACID para evitar perder transacciones de dinero o realizar dos veces el mismo pago.

• Los likes en redes sociales: seguramente una eventual consistency será suficiente, ya que por perder un like no va a pasar nada.

• Autenticación de usuarios: probablemente requieras ACID para prevenir problemas de seguridad.

• Análisis de datos: aquí quizás quieras priorizar el performance antes que una fuerte consistencia.

Así que la respuesta es: sí, ACID sigue importando. Cuando te encuentres en un caso donde priorices la consistencia de los datos, piensa en ACID como una herramienta que te va a ayudar a conseguir esa fuerte consistencia.

📅Bases de datos que soportan ACID hoy en día

Tradicionalmente, soportar las propiedades ACID era una característica de muchas bases de datos relacionales como MySQL o PostgreSQL. Sin embargo, en los últimos años, muchas bases de datos NoSQL también han comenzado a dar soporte parcial o completo a transacciones ACID. Entre las más famosas:

• Cassandra: ofrece transacciones atómicas, aisladas y duraderas con una consistencia a elegir entre eventual o fuerte según como se quieran las transacciones.

• DynamoDB: ofrece transacciones ACID desde 2018.

• CockroachDB: tiene soporte complete para transacciones ACID distribuidas.

• MongoDB: ofrece transacciones multi-document.

Así que no pienses que si quieres transacciones que cumplan con propiedades ACID te tengas que ir a una base de datos relacional, porque muchas NoSQL también lo soportan.

Fuentes:

• Kleppmann, Martin. Designing Data-Intensive Applications : The Big Ideas behind Reliable, Scalable, and Maintainable Systems. Sebastopol, CA, O’Reilly Media, 2017.

• https://www.hellointerview.com/learn/system-design/deep-dives/postgres

Conforme pasa el tiempo, surgen problemas que afrontar en nuestra base de datos:

• La cantidad de queries por segundo aumenta, con lo que necesitas añadir más CPUs para poder aguantar la carga.

• La cantidad de datos aumenta, con lo que necesitas añadir más almacenamiento en discos o RAM.

• Cuando un servidor falla y es necesario que otros servidores asuman sus responsabilidades. Para ello tendremos que mover todos esos datos y peticiones de un nodo a otro nuevo.

➡️ El proceso de mover toda esta carga de un nodo a otro dentro del clúster se conoce como rebalanceo.

No importa el esquema que hayas utilizado partición de la base de datos, hay una serie de requisitos mínimos que se buscan al hacer dicho rebalanceo:

• Después del rebalanceo, la carga (datos, peticiones de lectura y escritura) debe de ser distribuida de manera equitativa entre los nodos del clúster.

• Mientras ocurre el rebalanceo, la base de datos debe de seguir aceptando peticiones de lectura y escritura.

• No deberían de moverse más datos de los necesarios al realizar el balanceo. Así conseguiremos un rebalanceo más rápido y minimizaremos la carga por operaciones de E/S en disco y de red.

Sabiendo que estas son las cualidades que se buscan para rebalancear, vamos ahora a introducir un ejemplo.

Imaginemos que tienes un sistema montado con tu cliente, servidor y base de datos. Pero tu plataforma se ha hecho muy popular y tus servidores pueden escalar horizontalmente tranquilamente, pero tu base de datos ya no da abasto. Tienes que distribuir los datos que había en la base de datos entre diferentes nodos, vamos, lo que se conoce como sharding.

Este sistema se vería tal que así:

Lo que tenía antes en una sola instancia de mi base de datos, ahora lo tengo que repartir en 3 nodos separados. ¿Cómo lo hago? ¿Qué criterio utilizo para saber en qué base de datos tengo que guardar un dato u otro? Es decir:

¿Qué estrategia de rebalanceo utilizo?

Un primer intento: módulo N

El método más simple sería calcular el módulo (%) del hash de la key. Por ejemplo, si nuestra función para calcular el hash de una key devuelve un número en base 10, podríamos calcular el módulo N de ese número, siendo N el número de nodos que tenemos en total.

El algoritmo se vería tal que así:

• Primero, cogemos el id de la entidad y lo pasamos por la función hash que tenemos, lo cual lo convierte a un número.

• Ahora, cogemos ese número y calculamos el módulo (%) según el número de nodos que tengamos en nuestra base de datos.

• El resultado nos indica donde guardar dicho dato.

Un ejemplo donde queremos calcular donde van 3 keys y tenemos 3 bases de datos sería:

ID #15→ hash(15)→ 32→ 32 % 3 = 2 → Database 2
ID #99→ hash(99)→ 27→ 27 % 3 = 1 → Database 1
ID #66→ hash(66)→ 69→ 69 % 3 = 0 → Database 0

El problema con esta manera de particionar la base de datos es que si el número de nodos cambia, es decir, si la N cambia, vamos a tener que mover la mayor parte de las keys.

Por ejemplo, digamos que hash(12345)= 6. Si tenemos 3 nodos como en nuestro ejemplo, la key se asignará a la base de datos número 0 (porque 6 mod 3 = 0). Cuando añadas una base de datos más y tengas 4, tendrás que mover dicha key al nodo 2 (6 mod 4 = 2). Pero es que cuando añadas otra instancia más y tengas 5 nodos, tendrás que moverla al nodo 1 (6 mod 5 = 1). Y no es solo esa key, tendrás que mover de un lado a otro las keys de diferentes nodos cada vez que añadas o quites una base de datos.

Esto hace que el rebalanceo sea muy costoso y hace que movamos más datos de los necesarios durante el rebalanceo.

Tener un número fijo de particiones

Una solución común es crear más particiones que número de nodos, y asignar varias particiones a cada nodo. Por ejemplo, nuestro clúster de 3 nodos podríamos dividirlo en 300 particiones y así se le asignarían 100 a cada nodo. Esto va a hacer que sea mucho más fácil rebalancear los datos cuando se añadan o eliminen nodos.

Cuando añadas un nodo, dicho nodo va a simplemente robar unas cuantas particiones del cluster. Y cuando quites un nodo, pues lo mismo pero al contrario. Tienes que redistribuir las particiones entre los nodos existentes.

Solo las particiones enteras van a ser movidas entre nodos. El número de particiones no cambia, como tampoco cambia la partición que tiene asignada cada key. Mientras se hace la migración, las operaciones funcionan como en la configuración antigua hasta que se finaliza el cambio.

Aunque existe la posibilidad de dividir o combinar particiones, en la práctica muchas bases de datos eligen tener un número de particiones fijas desde que montas el sistema. Lo complicado es saber el número de particiones que vas a necesitar cuando tu sistema crezca. Pocas y largas particiones van a dificultar el balanceo, muchas particiones cortas van a generar mucho overhead. Lo ideal claro está, es encontrar un punto intermedio intentando predecir cómo va a crecer tu sistema.

Esta estrategia de balanceo es la que utilizan sistemas como Elasticsearch y Couchbase.

Consistent hashing

La última estrategia que vamos a presentar y en la que nos vamos a centrar se denomina consistent hashing. La clave principal es que vamos a distribuir nuestros datos y las bases de datos que disponemos en un anillo circular.

1. Supongamos que, al aplicar el hashing a nuestras keys, los valores resultantes puede ir del 0 al 100.

1. Cuando ponemos dichos valores en un anillo circular, donde la posición final va justo antes de la primera posición, nos quedaría algo así.

1. Ahora, distribuimos nuestros nodos de bases de datos a lo largo del anillo. Como tenemos 3 nodos, vamos a colocarlos en las posiciones 0, 33 y 66.

1. Y finalmente, solo nos queda distribuir nuestros datos. Para saber en qué nodo van nuestros datos, tenemos que calcular el hash de dicho dato y, en vez de hacer el mod 3 de dicho resultado, buscaremos el valor de dicho hash en el anillo y nos movemos siguiendo el sentido de las agujas del reloj hasta que encontremos un nodo. Si tenemos una key = 115 y hash(115) = 93, el nodo donde irá dicho dato es la base de datos 1.

Cómo añadir y quitar nodos

Vimos anteriormente que con la estrategia módulo N, al quitar o añadir nodos tendríamos que mover la mayoría de keys de sitio. Ahora que utilizamos consistent hashing, esto no va a ser así. Dado que cada servidor va a ser responsable de un arco de la circunferencia, añadir un servidor va a ser tan simple como mover ligeramente cada servidor en el anillo. De esta manera, solo un pequeño subconjunto de keys van serán reasignadas a un servidor diferente del que estaban.

Así, conseguiremos reducir el número de datos que se mueven durante el rebalanceo y, por lo tanto, disminuirán el número de cache misses durante este. Quitar un nodo del anillo será la misma operación que añadir un nodo pero a la inversa.

Esta solución ya es mucho mejor a lo que teníamos con la estrategia de modulo N. Pero hay una manera incluso mejor de repartir los nodos, una forma que al realizar el rebalanceo, consigue una redistribución más uniforme de las keys y generar un menor impacto en nuestro anillo.

Y esa manera es:

Virtual nodes

Los nodos virtuales (virtual nodes) son una extensión del consistent hashing que hace el sistema más resistente a distribuciones desequilibradas de datos en el anillo. La idea consiste en que cada base de datos va a ser representada por más de un nodo en el anillo. Esto lo podríamos conseguir con cualquiera de las siguientes 2 maneras:

• Añadiendo un prefijo a la base de datos al calcular su hash. Así, sin nodos virtuales estábamos calculando hash(DB 1), pero ahora tendríamos que calcular hash(DB 1_0), hash(DB 1_1), hash(DB 1_2), etc.

• Calcular la posición de los nodos de cada base de datos aplicando más de una función hash. Es decir, para saber la posición “*_0” utilizaríamos una función hash, para la posición “*_1” utilizaríamos otra función diferente y así.

En el caso de que la base de datos 4 falle:

• Las keys en “BD 4_1” serán distribuidas al nodo “2_2” así que irán a la base de datos 2.

• Las keys en “BD 4_3” serán distribuidas al nodo “3_2” así que irán a la base de datos 3.

• Las keys en “BD 4_2” serán distribuidas al nodo “1_3” así que irán a la base de datos 1.

• Las keys en “BD 4_0” serán distribuidas al nodo “1_2” así que irán a la base de datos 1.

Como vemos, esto hace que la carga de una base de datos caída se distribuya de manera más equitativa entre los diferentes nodos físicos. Cuantos más nodos virtuales uses por base de datos, más uniforme será la redistribución de la carga.

Conclusión

Con la llegada de los sistemas distribuidos, el consistent hashing es uno de esos algoritmos que solucionó un problema fundamental de manera elegante: cómo distribuir las carga entre bases de datos para luego minimizar la cantidad de datos que se redistribuyen al cambiar el número de servidores. Y todo esto simplemente poniendo los servidores en un anillo y siguiendo el sentido de las agujas del reloj.

Este algoritmo está integrado a día de hoy en tecnologías que utilizamos como Cassandra, DynamoDB o CDNs. Quizás no tendremos que implementarlo en los sistemas que construyamos en nuestro día a día, pero saber cómo funciona por adentro nos ayuda a tomar mejores decisiones cuando diseñemos sistemas distribuidos donde necesitemos particionar los datos.

Fuentes

• https://www.hellointerview.com/learn/system-design/deep-dives/consistent-hashing

• Artur Ejsmont. Web Scalability for Startup Engineers : Tips & Techniques for Scaling Your Web Application. New York, Mcgraw-Hill Education, 2015.

• Xu, Alex. System Design Interview : An Insider’s Guide. 2020.

• Kleppmann, Martin. Designing Data-Intensive Applications : The Big Ideas behind Reliable, Scalable, and Maintainable Systems. Sebastopol, CA, O’Reilly Media, 2017.

• Consistency (consistencia)

• Availability (disponibilidad)

• Partition tolerance (tolerancia a particiones)

¿Pero qué significan estas propiedades?

Consistencia

Todos los nodos/usuarios del sistema ven los mismos datos al mismo tiempo. Cuando una escritura se realiza en un nodo, todas las lecturas siguientes van a devolver el valor actualizado.

Disponibilidad

Cada petición realizada a un nodo disponible recibe una respuesta. Sin tener la garantía de que contenga la versión más actualizada de los datos.

Tolerancia a particiones

El sistema puede seguir en funcionamiento aunque parte de la red esté caída o parte de los mensajes se pierdan.

¿Dónde está la trampa?

Pues que, a no ser que estemos trabajando con una arquitectura monolito, seguramente estemos ante un sistema distribuido y, por lo tanto, la tolerancia a particiones es obligatoria. Por lo tanto, ya hemos elegido una de las dos propiedades que podemos tener.

Así que la pregunta clave termina siendo:

Cuando ocurre una partición en la red, ¿queremos priorizar la disponibilidad o la consistencia?

Imaginémonos el siguiente caso por un momento: nuestro sistema es una aplicación web que se utiliza en todo el mundo y tenemos una base de datos con todos los usuarios de nuestra aplicación en el mundo y, desplegadas, hay una instancia en Estados Unidos y otra en Europa. Dichas bases de datos son una réplica la una de la otra y están sincronizadas.

Pues ahora va John y quiere actualizar su perfil, por ejemplo, cambiar la biografía que aparece. Justo después de esto, va Paco y quiere leer la información que tiene John en su perfil. Ocurriría algo así:

1. John se conecta al servidor de Estados Unidos y actualiza su biografía.

2. La base de datos de Europa se sincroniza con la de EEUU y se trae los cambios.

3. Cuando Paco ve el perfil de John, ve su biografía actualizada.

Todo funciona de maravilla hasta que nos encontramos con una partición en la red. La conexión entre el clúster de Estadios Unidos y el de Europa se rompe.

Ahora bien, si consideramos el ejemplo anterior de nuevo, pero con esta partición de red, ¿qué deberíamos hacer?

• Opción A: devolver un error porque no podemos garantizar que nuestros datos estén actualizados (elegimos consistencia)

• Opción B: devolver datos que podrían estar desactualizados (elegimos disponibilidad)

Pues esta es la clave del teorema de CAP, la respuesta a esta pregunta definirá si esta parte de tu sistema prioriza la consistencia o la disponibilidad.

En este caso está claro, devolveríamos la biografía del usuario John, aunque no podamos asegurar que sea la versión más actualizada.

¿Cuándo elijo consistencia y cuando disponibilidad?

La realidad es que en la mayoría de sistemas van a tolerar algo de inconsistencia y deberían priorizar la disponibilidad. En estos casos lo que se llama eventual consistency es suficiente. Esto quiere decir que el sistema llegará eventualmente en algún punto a ser consistente, pero puede tardar segundos o incluso minutos.

Elegiremos consistencia en sistemas como:

• Un sistema que tenga reserva de tickets (Ticketmaster, Skyscanner): imagínate que hemos comprado tickets para un vuelo, pero a la hora de comprarlos hubo una partición de red y otra persona también los vio disponibles y compró los mismos tickets. Al aeropuerto llegarán dos personas con el mismo ticket.

• Inventario de una tienda e-commerce: si en una tienda como Amazon aparece que queda una sola Nintendo Switch 2 y la compras cuando hay una partición de red, quizás más de un usuario ha comprado la última unidad y alguien se queda sin ella.

• Sistemas de finanzas: los sistemas relacionados con stocks tienen que enseñar los últimos datos actualizados o si no, podrían haber problemas relacionados con los precios a los que se compraron o vendieron acciones.

Elegiremos disponibilidad en sistemas como:

• Redes sociales (Instagram): si un usuario actualiza su biografía, no pasa nada si otro usuario tarda un poquito más en verla actualizada.

• Plataformas de contenido (Netflix o Youtube): si alguien actualiza el nombre de una película en otro idioma, no pasa nada porque el título antiguo aparezca un poco más de tiempo.

• Páginas de reseñas (Google Maps): si un restaurante actualiza su horario, es mejor enseñar el horario antiguo que no enseñar nada.

Así que, de nuevo, ya para terminar, la pregunta que uno se tiene que preguntar es:

¿Sería un desastre si los usuarios viesen datos inconsistentes durante un rato?

Si la respuesta es sí, elige consistencia. Si es no, elige disponibilidad.

Fuentes:

• https://www.hellointerview.com/learn/system-design/deep-dives/cap-theorem.

• Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly Media.

• Ejsmont, A. (2015). Web Scalability for Startup Engineers. Apress.

• OLTP (procesamiento de transacciones online): los que están optimizados para procesar transacciones.

• OLAP (procesamiento analítico online): los que están optimizados para analíticas.

Y sí, los patrones de acceso a datos en uno y otro son muy diferentes.

OLTP: lo que maneja el usuario

Los sistemas OLTP suelen ser los que están de cara al usuario. Tienen que manejar muchas peticiones a la vez, así que las queries suelen pedir pocos registros, casi siempre por clave, para que el motor pueda usar un índice y responder rápido.

Aquí el cuello de botella suele estar en el tiempo que tarda el disco en buscar el dato exacto.

Dentro de este mundo OLTP hay dos formas comunes de organizar el almacenamiento:

• Estructura tipo log: no se sobreescriben ficheros, solo se añaden. Luego se eliminan ficheros obsoletos. Ejemplos: SSTables, LSM-trees, LevelDB, Cassandra, HBase, Lucene…

• Update-in-place: se sobreescriben páginas concretas en disco. El ejemplo clásico: B-trees, usados en la mayoría de bases de datos relacionales y muchas no relacionales también.

La ventaja de las estructuras tipo log es que convierten escrituras aleatorias en escrituras secuenciales, lo que es mucho más eficiente para escrituras en discos y SSDs. Por eso han ido ganando fama en los últimos años.

Si la estructura tipo log va a ofrecer un mejor rendimiento en las escrituras, la estructura con update-in-place va a hacerlo en lecturas.

OLAP: lo que manejan los analistas

Aquí ya no estamos hablando de miles de usuarios haciendo clics, sino de almacenes de datos o warehouses y otros sistemas de analíticas menos conocidos que utilizan los analistas de negocios. Los sistemas OLAP manejan muchas menos queries, pero cada una escanea millones de filas.

En estos casos el cuello de botella no es el tiempo de búsqueda, sino el ancho de banda del disco: cuántos datos puedes leer por segundo.

¿Y qué pasa con los índices?

Cuando tus queries requieren escanear secuencialmente una gran cantidad de filas, los índices dejan de ser tan relevantes. En cambio, se convierte mucho más valioso el poder codificar los datos de forma compacta y así poder minimizar la cantidad de datos que necesita la query leer del disco.

Por eso, en estos sistemas ha triunfado el almacenamiento por columnas. Permite leer solo las columnas necesarias, y además compactar los datos. Dado que en una misma columna van a haber muchos registros con el mismo valor, es mucho más facil compactar dichos datos. Esto hace que las queries vayan mucho más rápido.

Así quedaría una base de datos en base a columnas en vez de filas:

Y así quedaría comprimida utilizando bitmap encoding para una sola columna:

Tabla resumen

Estaba leyendo Designing Data-Intensive Applications de Martin Kleppmann y me acordé de cuando, en mi última empresa, teníamos que elegir una base de datos. Básicamente era: “vale, a buscar en internet qué base de datos escoger”.

Pero creo que, en ese momento, me faltaban nociones básicas. Especialmente sobre cómo en el mundo del desarrollo de software hemos llegado hasta los distintos modelos de base de datos que existen ahora. Entender el por qué surgieron SQL y NoSQL ayuda bastante a saber qué decisiones toman los programadores al elegir una base de datos para su sistema.

En este post voy a comparar brevemente bases de datos relacionales y basadas en documentos (aunque también mencionaré grafos).

Un repaso rápido al modelo relacional

Creo que todos conocemos el modelo relacional. Cuando sabes los requisitos del sistema, lo típico es empezar a normalizar los datos: es decir, organizar los datos en tablas, cada una con sus filas (registros) y columnas (atributos), y definir relaciones entre ellas usando primary keys y foreign keys.

Para interactuar con este tipo de base de datos se utiliza SQL (Structured Query Language), lo cual te permite hacer consultas declarativas como si trabajaras con conjuntos matemáticos.

¿Qué pasa con NoSQL?

El “rollo NoSQL” surgió por dos tendencias muy distintas:

• Bases de datos basadas en documentos, donde los datos vienen enteros en un solo documento y las relaciones entre documentos son poco frecuentes.

• Bases de datos de grafos, que van justo al otro extremo: intentan modelar casos donde todo puede estar relacionado con todo.

A día de hoy, los tres modelos (relacional, documentos y grafos) se usan bastante y cada uno tiene sentido en su propio dominio.

¿Qué hace especial al modelo basado en documentos?

Una base de datos basada en documentos permite guardar estructuras anidadas dentro del mismo documento padre. Por ejemplo, imagina un documento User que incluye un campo Schools, con una lista de colegios a los que fue ese usuario. Ahí estaríamos modelando una relación 1 a N directamente dentro del mismo documento.

En una base de datos relacional, eso serían dos tablas (User y School) relacionadas con una foreign key.

Cuando tienes relaciones simples (1 a 1, o incluso algunas N a N), ambos modelos pueden funcionar. La diferencia empieza a notarse cuando necesitas hacer muchas joins o cuando los datos están muy conectados.

Pros y contras de los modelos

He de decir que, tras los años, las bases de datos SQL se intentan parecer más a las bases de datos basadas en documentos (permitiendo el uso de JSON en columnas, entre otros), y las bases de datos basadas en documentos se intentan parecer más a las SQL, así ambas consiguen mayor flexibilidad para sus casos de uso.

Aquí te dejo una mini tabla para que te hagas una idea rápida:

Cosas que debes saber sobre las bases de datos basadas en documentos

• Flexibilidad no significa caos: aunque no tengas un esquema rígido, sigue siendo tu responsabilidad controlar qué estás metiendo en la base de datos. Se suele decir que en relacional se valida al escribir y en documentos al leer.

• Evita documentos enormes: aunque puedes guardar estructuras complejas (JSON, BSON, XML…), eso no significa que debas abusar. Si solo necesitas una parte del documento, la base de datos probablemente cargue todo. Además, cuando actualizas un documento, muchas veces se reescribe entero. Por eso suele recomendarse mantener los documentos pequeños y bien pensados.

• Para relaciones N a N, las bases de datos de documentos no son lo ideal. Puedes denormalizar, pero entonces mantener la consistencia se vuelve más complicado. Y si usas código en la aplicación para simular joins, el rendimiento baja y la complejidad del código sube.

Conclusión rápida

• ¿Tu modelo tiene datos muy conectados? → Relacional o grafos.

• ¿Necesitas flexibilidad, escalabilidad y acceso rápido a una estructura de datos entera y concreta para tu caso de uso? → Modelo basado en documentos.

• ¿Tienes muchas relaciones complejas N a N? → El modelo en documentos se te va a quedar corto.

Y como resumen simple:
👉 Para datos muy interconectados, el modelo en documento es 💩, el relacional es aceptable, y los grafos son lo más natural.

Some time ago, I asked my first manager as a software engineer, Andrea Carrozo, to recommend me some books to healp me learn more about databases. Andrea immediately suggested NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence by Pramod J. Sadalage and Martin Fowler. As I write about it now, I revisited Andrea’s personal website (jonnyjava.net) and noticed that he had even listed it as the first book to read in his recommended databases learning path.

Although I’ve read several programming books, I hadn’t yet explored one focused exclusively on NoSQL databases. So, it felt like the right time to visit my local bookstore and pick up a fresh copy.

I’ll be going through the book chapter by chapter, sharing the key insights and lessons I learn along the way.

Chapter 1: Relational Databases and NoSQL

Relational Databases:

What they solve:

• Getting at Persistent Data: they allow more flexibility and speed than file systems when getting small bits of information from big amounts of data.

• They solve concurrency: the problem of having many people looking at the same data at once and even modifying it. Relational databases help handle this by controlling all access to their data through transactions. This isn’t the cure, you will also get transactional errors. But with transactions, you can make a change, and if an error occurs during the processing of the change you can roll back the transaction to clean things up.

• Integration: using one database for multiple applications (integration database)

• A Standard Model: the core mechanisms of relational databases is the same. allowing developers to learn it an apply to multiple projects.

Impedance Mismatch from Relational Databases

Given that the relational data model organizes data into a structure of tables and rows, if you want to use a richer data structure, you have to translate it to that representation. This difference between the relational model and the in-memory data structure is called impedance mismatch and it has been frustrating for application developers.

NoSQL

How it appeared

1. ➡️ 1990s dot-com bubble

2. ➡️ Growth in data from websites

3. ➡️ Need more computing resources: use clusters

4. ➡️ Relational databases are not designed to be run efficiently on clusters: mismatch

5. ➡️ Organizations consider an alternative route to data storage

6. ➡️ Google and Amazon (who were the forefront of running large clusters) produce highly influential papers: BigTable from google and Dynamo from Amazon.

There is no proper definition for NoSQL databases but rather some common characteristics:

• They don’t use the relational model

  • They run well on clusters

• They are generally open-source projects

• They are schemaless, allowing you to freely add fields to database records without having to define any changes in structure first.

The two primary reasons to consider NoSQL are:

• Handle data access with size and performance that demand a cluster.

• Improve the productivity of application development by using a more convenient data interaction style.

Extra

In order to make the polyglot persistence world to work, organizations need to shift from integration databases to application databases.

We don’t generally consider NoSQL databases a good choice for integration databases.

Chapter 2: Aggregate Data Models

A data model is the model through which we perceive and manipulate our data.

Agregate orientation takes a different approach. It recognizes that often, you want to operate on data in units that have a more complex structure than a set of tuples.

➡️ An aggregate is a collection of data that we interact with as a unit.

If we’re running on a cluster, we need to minimize how many nodes we need to query when we are gathering data.

➡️ Aggregates make it easier for the database to manage data storage over clusters.

It’s often said that NoSQL databases don’t support ACID transactions and thus sacrifice consistency. This is a rather sweeping simplification. In general, it’s true that aggregate-oriented databases don’t have ACID transactions that span multiple aggregates. Instead, they support atomic manipulation of a single aggregate at a time. This means that if we need to manipulate multiple aggregates in an atomic way, we have to manage that ourselves in the application code.

➡️ Aggregates form the boundaries for ACID operations with the database.

In practice, we find that most of the time we are able to keep our atomicity needs to within a single aggregate; indeed, that’s part of the consideration for deciding how to divide up our data into aggregates.

With key-value databases, we expect to mostly look-up aggregates using a key. With document databases, we mostly expect to submit some form of query based on the internal structure of the document; this might be a key, but it’s more likely to be something else.

➕ the main difference between key-value and document databases is that in the first one, the aggregate is opaque to the database - just some big blob of mostly meaningless bits. In contrast, a document database is able to see a structure in the aggregate.

Column-family models divide the aggregate into column families, allowing the database to treat them as units of data within the row aggregate.

Chapter 3: More about Data Models

Operating across multiple aggregates and managing lots of relations on NoSQL databases based on aggregates is awkward.

• If you want to have data based on lots of relationships, you should prefer a relational database. But relational databases aren’t that excellent with complex relationships either.

• Graph databases are good doing this. They are based on an opposite model from relational databases: small records with complex interconnections. A graph database allows you to query that network with query operations designed with this kind of graph in mind so making traversal along the relationships is cheap.

• Agregate-oriented databases often compute materialized views to provide data organized differently from their primary aggregates. This is often done with map-reduce computations.

Schemaless databases

• A common factor between all the forms of NoSQL databases is that they are schemaless.

• This means that when you want to store data, you dont need to define schema for it. This allows you to easily change your data storage as you learn more about your project.

• It also facilitates handling non-uniform data: data where each record has a different set of fields.

• Schemaless databases althought appealing, they bring problems of their own like:

  • Whenever we write a program that accesses data, the program relies on some form of implicit schema and assume something about the type of data stored within that field. So, however schemaless our database is, there is an implicit schema. This implicit schema is a set of assumptions about the data’s structure in the code to manipulate the data.

    • With an implicit schema it means that to understand what data there is present, you have to dig into the application code.

    • The database remains ignorant of the schema and it can’t use it to help it decide how to store and retrieve data.

• So, although NoSQL fans often criticize relational schemas for having to be defined front and being inflexible, that’s not really true. Relational schemas can be changed at any time with standard SQL commands.

Chapter 4: Distribution Models

These are the following ways of running a database on a cluster of servers:

• Single Server. The simplest distribution option and the one the authors of the book would most often recommend - no distribution at all. It consists of just running the database on a single machine that handles all the reads and writes to the data store. It is prefered because it eliminates all the complexities that all the other options introduce.

• Sharding. It distributes different data across multiple servers, so each server acts as the single source for a subset of data.

• Replication. Copies data across multiple servers, so each bit of data can be found in multiple places. Replication comes in two forms:

  • Master-Slave Replication. Makes one node the authoritative copy that handles writes while slaves synchronize with the master and may handle reads.

  • Peer-to-Peer Replication. Allows writes to any node and the nodes coordinate to syncrhonize their copies of the data.

  • Master-slave replication reduces the chance of update conflicts, but peer-to-peer replication avoids loading all writes onto a singles point of failure.

• Combining Sharding and Replication. These strategies can be combined to gain benefits from both of them like master-slave replication and sharding or peer-to-peer replication with sharding which is common strategy for column-family databases.

Chapter 5: Consistency

One of the biggest changes from a centralized relational database to a cluster-oriented NoSQL database is in how you think about consistency. Relational databases try to exhibit strong consistency by avoiding all the various incosistencies introduced below.

Write-write conflicts occur when two clients try to write the same data at the same time. Read-write conflicts occur when one client reads incosistent data in the middle of another client’s write.

Approaches for maintaining consistency in the face of concurrency as often described as pessimistic or optimistic:

• Pessimistic approaches works by preventing conflicts from occurring. It lock data records to prevent conflicts.

• Optimistic approaches lets conflicts occur, but detects them and takes action to sort them out.

Often, when people first encounter these issues, their reaction is to prefer pessimistic concurrency because they are determined toa void conflicts. While in some cases this is the right answer, there is always a tradeoff. Concurrent programming involves a fundamental tradeoff between safety (avoiding errors such as update conflicts) and liveness (responding quickly to clients). Pessimistic approaches often severely degrade the responsiveness of a system to the degree that it becomes unfit for its purpose.

Some claims about NoSQL databases and the consistency on its updates.

A common claim we hear is that NoSQL databases don’t support transactions and thus can’t be consistent. Such claim is mostly wrong because it glosses over lots of important details. Out first clarification is that any statement about lack of transactions usually only applies to some NoSQL databases, in particular the aggregate-oriented ones. In contrast, graph databases tend to support ACID transactions just the same as relational databases.

Secondly, aggregate-oriented databases do support atomic updates, but only within a single aggregate. This means that you will have logical consistency within an aggregate but not between aggregates.

Data that is out of date is generally referred to as stale.

The basic statement of the CAP theorem is that, given the three properties of Consistency, Availability, and Partition tolerance, you can only get two.

The CAP theorem states that if you get a network partition, you have to trade off availability versus consistency.

• Distributed systems see read-write conflicts due to some nodes having received updates while other nodes have not. Eventual consistency means that at some point the system will become consistent once all the writes have propagated to all the nodes.

• To get good consistency, you need to involve many nodes in data operations, but this increases latency. So you often have to trade off consistency versus latency.

• Durability can also be traded off against latency, particularly if you want to survive failures with replicated data.

• You do not need to contact all replicants to preserver strong consistency with replication. You just need a large enough quorum.

Chapter 6: Version Stamps

Version stamps help you drect concurrency conflicts. When you read and then update data, you can check the version stamp to ensure nobody updates the data beteween your read and write.

Implementations of version stamps are:

• Counters

• GUIDs

• Content hashes

• Timestamps

• A combination of these

Timestamps are simple but problematic because is difficult to ensure that all the nodes have a consistent notion of time. A counter is usually better than timestamps.

The most common approach use by peer-to-peer NoSQL systems is a vector stamp. It would look like [blue: 43, green: 54, black: 5]

Chapter 7: Map-Reduce

A map-reduce is a pattern to allow computations to be parallelized over a cluster. It is composes of a map function, which performs filtering and sorting, and a reduce method, which performs a summary operation.

• The map task reads data from an aggregate and summarizes it to relevant key-value pairs. Maps only read a single record at a time and can thus be parallelized and run on the node that stores the record.

• Reduce tasks take many values for a single key output from map tasks and summarize them into a single output. Each reducer operates on the result of a single key, so it can be parallelized by key.

• Reducers that have the same form for input and output can be combined into pipelines. This improves parallelism and reduces the amount of data to be transferred.

• Map-reduce operations can be composed into pipelines where the output of one reduce is the input to another operation’s map.

• If the result of a map-reduce computation is widely used, it can be stored as a materialized view.

  • Materialized views can be updated through incremental map-reduce operations that only compute changes to the view instead of computing again everything from scratch.

Recently, my mentor in employment and work culture in Korea, Minhee Jung, recommended this book to me to better understand the ways in which we can make connections. At first, I was not sure if the content of the book would clash too much with my way of thinking.

I come from a Spanish family where Christian values such as generosity are implicit in my culture. This, combined with a strong sense of helping others passed on to me by my parents, fueled my childhood dream of becoming a policeman, and later, a fireman. However, my aspirations changed and ended up changing my dreams again to become a software engineer. I believe that my life experiences have shaped my perspective, and sometimes restrained my ability to fully embody those giving values.

This book has offered me a new perspective on something that has always brought me fulfillment: helping others. It has reawakened this desire in me again as well as showing me how successful people achieve their dreams while helping others.

Below, I have saved quotes and annotations divided by the different themes of the book. This is according to my understanding of the book, your experience may be different and these annotations may or may not be that helpful to you.

Givers, takers and matchers

The main argument in the book is that in a networked world success depends on how we interact with others. The author suggests there are three different styles: Givers, those who give to others without an expect for a return; Matchers, those who give to get something in return; and Takers, those who are only motivated about what they can get from others.

The giving mentality

“I’ll sum up the key to success in one word: generosity,” writes Keith Ferrazzi. “If your interactions are ruled by generosity, your rewards will follow suit.”

The main quality of givers that is described through the read of the whole book is generosity. This is the main characteristic of givers that make them what they are, being free in giving or sharing.

Instead of aiming to succeed first and give back later, you might decide that giving first is a promising path to succeeding later.

Giving to get something back is a matcher’s mentality. Givers don’t do things to succeed; if you do, it probably won’t work.

The people at the bottom of the ladder are givers, but also the most successful ones.

The way these both givers operate make the difference between becoming a giver who is treated as a doormat and becoming one who knows how to identify people who want to just take things from them, the takers.

This is what I find most magnetic about successful givers: they get to the top without cutting others down, finding ways of expanding the pie that benefit themselves and the people around them. Whereas success is a zero-sum in a group of takers, in groups of givers, it may be true that the whole is greater than the sum of the parts.

They way givers treat others

When selling, givers ask questions in a way that conveys the desire to help customers, not take advantage to them.

When selling, givers ask questions and try to understand the client needs. They believe they are there to help their client. That is why clients trust sellers who are givers, because they really care about them and their necessities.

But when givers are advocating for someone else, pushing is closely aligned with their values of protecting and promoting the interests of others: givers can chalk it up to caring. And by offering relational accounts, givers do more than just think of themselves as agents advocating for others; they present themselves as agents advocating for others, which is a powerful way to maintain their self-images and social images as givers.

Givers are open about the fact that they are there to help, pushing themselves to protect and promote the interests of others. That helps them build their image.

In my own research, I’ve found that because of their dedication to others, givers are willing to work harder and longer than takers and matchers.

Givers are willing to put all their efforts for others, thats why they are also the ones that have to exert their efforts out of a sense of responsibility and work harder than anyone else.

How givers think of others

As a giver, Inman built this championship team with an approach that mirrored C. J. Skender’s: seeing potential in players where others didn’t.

Often, when people has to give a value to people, they tend to see what the other person can put on the table. Successful givers don’t act like that. They see the potential in the other person and think of how far they can go in the future. They can find diamonds in the rough.

“Even when people are well intentioned,” writes LinkedIn founder Reid Hoffman, “they tend to overvalue their own contributions and undervalues those of others.”

When we work in groups, our perception makes us to underestimate others’ contributions. We think of a higher estimation for our work than work done by others.

Givers like Meyer do this naturally: they take care to recognize what other people contribute

Another attribute of givers, they recognize other’s people work, they don’t underestimate other’s efforts.

Networking and relationship building

Adam Rifkin believes that we should see networks as a vehicle for creating value for everyone, not just claiming it for ourselves.

The traditional way of networking is based on the norm of reciprocity, the famous “quid pro quo”, you get something and you give something back. But the giver’s approach is to build networks to be able to generate more value. In other words, give and take back in order to give or help more people.

when everyone contributes, the pie is largers, and givers are no longer stuck contributing for more than they get.

When giving, force the people you are helping to also give so they help other people.

Advice seeking is a form of powerless communication that combines expressing vulnerability, asking questions and talking tentatively. When we ask others for advice, we’re posing a question that conveys uncertainty and makes us vulnerable. Instead of confidently projecting that we have all the answers, we’re admitting that others might have superior knowledge.

Asking others for advice is also a giver’s way of acting.

The 5-minute rule

His giving is governed by a simple rule: the five-minute favor. “You should be willing to do something that will take you five minutes or less for anybody”

This is the 5-minute rule. Is not about thinking about what the other person can do for you. Is not about trading value, but adding value to the other person. You shouldn’t be thinking about whether if the people you help will contribute back to you. Be confident that someone else will do something for you down the road.

Weak ties and dormant ties

One of Rifkin’s maxims is “I believe in the strength of weak ties”

Strong ties are our close friends and colleagues, the people we really trust. Weak tries are our acquaintances, the people we know casually.

Strong ties are people who are close to you and somehow share the same social circles. Since weak ties are often formed by people who are not close to you, these people get you to know others from different circles that you wouldn’t be able to get to to know. For instance; to land a new employment, weak ties are more likely to help you get there than strong ties with people you know better.

Dormant ties offer the access to novel information that weak ties afford, but without the discomfort.

When you made some kind of tie with someone, that tie is not lost over the time, it just becomes a dormant tie. Dormant ties are very powerful because you have already made an environment of mutual trust we was built a long time ago and makes the conversation today smoother. You just need to reactivate the dormant tie.

Balancing self-interest and altruism: otherish givers

If takers are selfish and failed givers are selfless, successful givers are otherish: they care about benefiting others, but they also have ambitious goals for advancing their own interests.

Be a otherish, not a selfless giver. You need to also act for your own interests and avoid becoming a doormat. You need to be a hybrid engine between “self-interest” and “caring for others”.

These resilient health care professionals were otherish givers: they reported that they enjoyed helping other people and often went out of their way to do so, but weren’t afraid to see help when they needed it.

To be a giver is to go out of your way to help others but also to get help when you need it. This is the moment when you take back what you payed in forward. This help could be for yourself or, again, help others.

I’ll also argue that an otherish style helps givers sidestep the land mines of being too empathetic and too timid…

Successful givers can’t be that empathetic and timid.

Adapting giving strategies

Trust is one reason that givers are so susceptible to the doormat effect: they tend to see the best in everyone, so they operate on the mistaken assumption that everyone is trustworthy.

Successful givers need to know who’s likely to manipulate them so that they can protect themselves.

The most effective negotiators were otherish: they reported high concern for their own interests and high concern for their counterparts’ interests.

The dangers lie less in giving itself, and more in the rigidity of sticking with a single reciprocity style across all interactions and relationships.

… Although many successful givers start from the default of trusting others’ intentions, they’re also careful to scan their environments to screen for potential takers, always ready to shift from feeling a taker’s emotions to analyzing a taker’s thoughts, and flex from giving unconditionally to a more measured approach of generous tit for that. And when they feel inclined to back down, successful givers are prepared to draw reserves of assertiveness from their commitments to the people who matter to them.

As a giver, you can’t act the same way with all people. Givers need to change their strategies so they are not used by others. They need to recognize takers and change their strategy.

The impact of giving in professional settings

Successful givers get to the top without stepping on others, that is something a taker would do.

We spend the majority of our waking hours at work. This means that what we do at work becomes a fundamental part of who we are. If we reserve giver values for our personal lives, what will be missing in our professional lives? By shifting ever so slightly in the giver direction, we might find our waking hours marked by greater success, richer meaning, and more lasting impact.

We spend most of our lives working. If we want to live as a giver, we should be givers at work too.

“Focus attention and energy on making a difference in the lives of others, and success might follow as a by-product.”

This is the mentality that givers should adopt. Immediate success may not be possible, but by embracing this mindset, success will come sooner or later.

Hey there! I’m Juanjo, a 24-year-old software engineer who has been working for an insurtech company for the last 2 and a half years after graduating from university. Actual picture of me:

I come from a small city in Spain called Seville that is mostly known for our country’s famed traditions like flamenco and bullfighting. However, I personally enjoy my hometown for how welcoming our people are and its food (we’ve got some delicious tapas here ⬇️).

Food talks aside, as I navigate through the twists and turns of my career in the tech industry, I’ve decided to embark on a new adventure – starting this blog.

My journey so far

After graduating in Computer Engineering from the University of Seville in 2021, I was contacted by Joanna through LinkedIn for a spot in Coverwallet’s Excellence Fellowship program (an internship program for students with high marks). Little did I know, the real challenges lay ahead as I stepped into the world of tech.

Why this blog?

Reflecting on my journey, I realized there were gaps in my knowledge and experience that I hadn’t anticipated. The COVID-19 pandemic disrupted my last university years, leaving me struggling to find my footing in the job market. Due to the impact of the pandemic, I believe that I missed lots of opportunities to make connections and discuss with my colleagues how to continue with our careers as Software Engineers.

Now, with almost three years of industry experience under my belt, I’ve come to appreciate the importance of building a personal brand and sharing insights with fellow tech enthusiasts. I should have started this time ago, but I didn’t even know this was a thing. Late to the party or not, I will give it a try!

What to expect

This blog will be my tech playground, where I’ll share everything from tech tutorials and book reviews to anecdotes about fixing the local flower shop’s website. It’s a work in progress, and I invite you to join me on this journey of self-discovery and growth.

Final thoughts

Thank you for joining me on this new chapter 🫶. Whether you’re a seasoned developer or just starting out, I hope you can take something from my experiences or even be inspired by them.

Contact

Feel free to contact me or send me a LinkedIn message anytime! 😉

• LinkedIn: Juanjo Requena

• Email: juanjorek@gmail.com

• Github: wuaho

• This blog’s profile: @Juanjo Requena