Aprende reconstruyendo Redis y Git

Si alguna vez usaste Redis para cachear respuestas o Git para sobrevivir a un merge conflict, seguramente te pasó esto: sabes usar la herramienta, pero no siempre entiendes por qué se comporta así. Puedes memorizar comandos, copiar configuraciones y seguir tutoriales, pero cuando aparece un bug raro, una latencia extraña o un historial roto, te quedas mirando la pantalla sin una explicación sólida.

La propuesta de aprender reconstruyendo sistemas reales va justo al centro de ese problema. En vez de empezar por teoría abstracta, tomas un sistema que ya funciona, lo desmontas por partes y lo vuelves a construir. Eso te obliga a entender decisiones concretas: cómo se guardan datos, cómo se indexan, qué trade-offs hay entre velocidad y consistencia, y por qué ciertas APIs existen en primer lugar. El proyecto de Ship That Code, inspirado en aprender reconstruyendo Redis, Git y una base de datos desde cero, apunta exactamente a eso: aprender haciendo, pero con sistemas que sí usan millones de personas.

Por qué reconstruir te enseña más que solo consumir cursos

Un curso tradicional suele ir de concepto a concepto. Te explica qué es una base de datos, qué es un commit, qué es un cache hit, y luego te muestra ejemplos. Eso sirve para arrancar, pero no siempre te deja con intuición de sistema. Cuando reconstruyes, el orden cambia: primero tropiezas con una limitación, luego buscas la razón técnica, y recién después entiendes la teoría. Ese recorrido se te queda más pegado porque está anclado a decisiones reales.

Hay una diferencia importante entre saber que Redis es rápido y entender de dónde sale esa rapidez. Cuando implementas una estructura simple tipo key-value en memoria, descubres que el acceso O(1) no te salva de todo. Todavía tienes que pensar en serialización, expiración, persistencia, memoria fragmentada y concurrencia. Lo mismo pasa con Git: puedes usar git rebase durante años sin entender cómo un commit apunta a un árbol, cómo se calcula un hash o por qué un merge no es magia sino manipulación de objetos y referencias.

La teoría se vuelve útil cuando ya viste el problema

Si intentas aprender B-trees, hashing o DAGs sin contexto, el contenido puede sentirse suelto. Pero si antes construiste un mini motor de almacenamiento, una vez que te topas con el problema de buscar por clave o recorrer historial, la teoría deja de ser una lista de términos. Se convierte en una respuesta a algo que ya intentaste resolver.

Eso no significa que debas reinventar todo desde cero en producción. Significa que, para aprender de verdad, conviene construir versiones mínimas de sistemas reales. La versión mínima de Git no necesita soporte para cien protocolos. La versión mínima de Redis no necesita cluster, Lua ni módulos. Necesita lo suficiente para que tú veas la mecánica interna.

Aprender por reconstrucción también mejora tu criterio

Cuando trabajas en backend, no solo importa si algo funciona. Importa cuánto cuesta mantenerlo, escalarlo y depurarlo. Reconstruir te da criterio para hacer mejores preguntas en el trabajo: ¿esto debería vivir en memoria o en disco?, ¿qué pasa si se cae el proceso?, ¿cómo recuperamos estado?, ¿qué costo tiene cada lectura?

Ese criterio es especialmente valioso si trabajas en equipos pequeños o en startups de Latinoamérica, donde muchas veces no hay tiempo para hacer una prueba de concepto completa antes de elegir una tecnología. Si entiendes los principios, te equivocas menos al escoger herramientas.

Qué aprendes al reconstruir Redis

Redis parece simple desde afuera: guardas una clave, recuperas un valor, aplicas TTL y listo. Pero su valor real está en la cantidad de decisiones pequeñas que resuelve bien. Si lo reconstruyes en versión básica, aprendes mucho más que “cache”. Aprendes sobre estructuras de datos, latencia, memoria y persistencia.

El primer paso suele ser un servidor que acepte comandos básicos y mantenga un diccionario en memoria. Ahí ya aparece un aprendizaje clave: la rapidez no viene de la complejidad, sino de evitar trabajo innecesario. No consultas un disco, no haces joins, no recorres tablas enteras. Respondes con una estructura preparada para acceso directo.

TTL, expiración y memoria: el detalle que muchos subestiman

Un cache sin expiración es una fuga de memoria con buena prensa. Al reconstruir Redis, el TTL te obliga a resolver preguntas incómodas: ¿eliminas claves al leerlas o con un proceso de limpieza?, ¿cómo manejas miles de expiraciones sin barrer toda la memoria cada segundo?, ¿qué pasa si la clave vence mientras se está leyendo?

Ahí ves por qué un sistema real necesita más que un diccionario. Necesita políticas, procesos de mantenimiento y decisiones de rendimiento. Un diseño ingenuo funciona con 100 claves. Con 1 millón, ya no.

Persistencia: cuando la memoria sola no alcanza

La parte más interesante llega cuando agregas persistencia. Redis ofrece mecanismos como RDB y AOF, y según la documentación oficial, cada opción tiene su propia lógica de recuperación y costo. Si tú construyes una versión mínima, entiendes por qué escribir todo en disco en cada cambio es caro, y por qué guardar snapshots periódicos o logs de operaciones cambia el equilibrio entre durabilidad y velocidad.

No necesitas replicar toda la complejidad de Redis para aprender. Basta con implementar una escritura append-only sencilla y luego probar qué pasa si el proceso muere a mitad de una operación. Esa prueba te enseña más que una hora de slides.

Qué aprendes al reconstruir Git

Git tiene fama de ser difícil, pero parte de esa fama viene de que mucha gente aprende su interfaz antes de entender su modelo de datos. Si tú reconstruyes una versión mínima, Git deja de parecer una caja negra. Ves que un commit no es solo un mensaje con fecha, sino un objeto que apunta a un árbol y a commits previos. Esa estructura explica por qué el historial es un grafo acíclico dirigido, no una lista lineal simple.

Cuando implementas un VCS básico, el primer gran aprendizaje es que versionar no significa copiar todo cada vez. Puedes guardar snapshots completos al principio y luego pasar a deltas o referencias. En ese punto empiezas a pensar como diseñador de sistemas: ¿qué optimiza espacio?, ¿qué optimiza lectura?, ¿qué complica el merge?

Objetos, hashes y referencias

Git usa hashes para identificar objetos de forma estable. Eso te da inmutabilidad práctica: si el contenido cambia, cambia el hash. Cuando haces una reconstrucción simple, puedes empezar con SHA-1 o SHA-256 según el enfoque, pero lo importante no es el algoritmo en sí. Lo importante es entender que el hash funciona como identidad del contenido.

Ese detalle explica muchas cosas que suelen parecer raras cuando usas Git:

1. Un commit no se “edita” realmente, se crea uno nuevo.
2. Las ramas no son carpetas mágicas, son referencias a commits.
3. Un merge no mezcla archivos a ciegas, resuelve dos historias que divergen.
4. El reflog existe porque las referencias cambian con el tiempo.

Merge, diff y conflicto real

Si solo implementas init, add y commit, te pierdes la parte más humana del sistema: el conflicto. Reconstruir un diff básico y un merge de dos ramas te obliga a enfrentar el problema real de combinar cambios. Ahí entiendes por qué Git no puede adivinar la intención del usuario y por qué algunas fusiones requieren intervención manual.

En la práctica, esto cambia cómo trabajas. Cuando ves un conflicto, ya no lo tratas como un error abstracto. Lo entiendes como la consecuencia natural de dos estados que compiten sobre el mismo archivo o bloque de texto.

Cómo se ve una base de datos desde cero

Una base de datos desde cero no tiene que empezar con SQL completo ni con transacciones avanzadas. Puede empezar con un archivo, una estructura de páginas, un índice simple y lecturas por clave. Aun así, el aprendizaje es enorme porque te obliga a conectar almacenamiento, formato de datos y acceso eficiente.

El problema central es siempre el mismo: guardar mucha información y recuperarla rápido sin romperla. Desde ahí aparecen temas como buffering, páginas, journaling, índices y planificación de consultas. Si tú lo construyes en pequeño, cada capa tiene un motivo visible.

Un recorrido mínimo para entenderla bien

Una ruta razonable para reconstruir una base de datos pequeña sería esta:

1. Guardar registros en un archivo plano.
2. Agregar lectura y escritura por clave.
3. Crear un índice en memoria para evitar scans completos.
4. Persistir el índice o reconstruirlo al iniciar.
5. Añadir un WAL para recuperar cambios después de un crash.
6. Probar inserciones, borrados y actualizaciones bajo carga.

Ese camino te enseña por qué las bases de datos reales hacen tanto trabajo invisible. Una consulta simple puede involucrar indexación, lectura de páginas, cache del sistema operativo y recuperación ante fallos.

Tabla comparativa: qué entiendes al reconstruir cada sistema

Esa tabla resume una idea simple: el valor no está en copiar la herramienta final, sino en ver qué problema resuelve cada capa. Si tú entiendes eso, luego leer documentación te resulta mucho más útil.

Cómo practicar sin perder semanas en un agujero negro

Reconstruir sistemas reales suena bien, pero también puede convertirse en un proyecto infinito si no pones límites. La clave es trabajar con objetivos pequeños y medibles. No intentes clonar Redis completo ni Git completo. Intenta construir una versión que te enseñe una sola idea por iteración.

Por ejemplo, en una semana puedes construir un key-value store con comandos básicos. En otra, puedes agregar expiración. Luego, persistencia simple. Después, un modo de recuperación. Lo mismo con Git: primero objetos, luego commits, luego branches, luego merge. Si cada paso funciona por separado, el aprendizaje se acumula sin ahogarte.

Un plan de 4 semanas que sí cabe en la agenda

1. Semana 1: servidor mínimo y almacenamiento en memoria.
2. Semana 2: persistencia básica en archivo o log append-only.
3. Semana 3: índices, hashes o referencias para acelerar búsquedas.
4. Semana 4: recuperación tras reinicio y pruebas de fallos.

Ese plan no te convierte en experto, pero sí te da una base real. Y si trabajas full-time, eso ya es bastante. Mejor 4 semanas con entregables claros que 4 meses de tutoriales inconexos.

Herramientas que te ayudan a aprender de verdad

No necesitas un stack extravagante. De hecho, mientras más simple sea el entorno, mejor ves el sistema. Un lenguaje como Go, Rust, TypeScript o Python puede servir, siempre que te permita iterar rápido y probar casos de borde.

Para afinar el criterio, también vale leer documentación oficial de herramientas que ya usas. Por ejemplo, la documentación de Git te permite contrastar tu implementación mínima con el comportamiento real. Y la documentación de SQLite es útil si quieres entender cómo un motor pequeño toma decisiones de almacenamiento y recuperación.

Cuándo sí conviene reconstruir y cuándo no

Reconstruir es excelente para aprender fundamentos, pero no es la mejor estrategia para todo. Si tu objetivo es entregar una feature mañana, no te conviene pasar tres semanas implementando un índice propio. Si tu objetivo es crecer como backend dev, sí puede valer mucho la pena dedicar tiempo a una versión mínima de un sistema real.

La pregunta útil no es “¿puedo reemplazar Redis?” sino “¿qué entiendo después de hacerlo?”. Si al final sabes por qué un cache falla, cómo se recupera un historial o dónde se rompe una base de datos, el ejercicio ya pagó parte de su costo.

También hay un beneficio indirecto: aprendes a leer código ajeno con menos miedo. Cuando ves una implementación madura, ya no la percibes como una muralla de abstracciones. Identificas piezas familiares: almacenamiento, índices, serialización, invalidación, recuperación, concurrencia.

Tabla resumen

Aprender reconstruyendo no reemplaza la teoría. La ordena. Primero ves el problema, luego entiendes la solución y después lees la documentación con otra cabeza. Si trabajas con backend, infraestructura o datos, ese cambio de orden puede ahorrarte horas de confusión y ayudarte a tomar mejores decisiones.

La idea de Ship That Code va en esa dirección: menos consumo pasivo y más construcción con intención. No necesitas rehacer internet. Necesitas elegir un sistema que usas todos los días, bajarlo a su versión mínima y entender por qué funciona. Redis, Git y una base de datos desde cero son buenos candidatos porque te obligan a tocar memoria, persistencia, historial y recuperación. Eso sí cambia cómo programas.