✈️ Por qué me uní a LATAM Airlines y cómo estudio un sistema nuevo

Este mes me uní a LATAM Airlines como Senior Backend Engineer. Sigo en esa etapa inicial de aprender nombres, descifrar siglas internas que parecen otro idioma, leer documentación de arquitectura y dibujar diagramas a mano que seguro voy a redibujar tres veces a medida que aparezcan los casos borde que ningún documento menciona.

Antes de que la rutina normalice todo lo que hoy es nuevo, quiero dejar por escrito tres cosas: por qué di el salto hacia la industria aérea, qué problemas de sistemas distribuidos vamos a resolver y cómo organizo mi sistema de estudio en estas primeras semanas para absorber contexto rápido sin quemarme en el intento.

🛫 De pagos y antifraude a operaciones aéreas

Mis últimos años transcurrieron en fintech, comercio electrónico y programas de lealtad de alta concurrencia: motores antifraude en tiempo real para puntos de venta, plataformas centralizadas de autenticación e infraestructura de seguridad en compañías como Mercado Libre y Leal.

Esos sistemas te entrenan para mirar de cerca los percentiles altos de latencia (p95/p99), la contención en bases de datos y la integridad transaccional. Una condición de carrera en un cobro o en un canje de puntos cuesta dinero en segundos, así que las cuentas tienen que cuadrar al centavo.

Una aerolínea suma un peso físico y operativo distinto. Cuando un pasajero está frente a un kiosco del aeropuerto o en la fila de embarque con una maleta en la mano, una pantalla trabada detiene una fila real de personas. Detrás de una sola acción en la web o en la app móvil, los datos de ese viaje cruzan varios países, marcos regulatorios, husos horarios y sistemas críticos antes de que el avión se separe de la puerta.

Si un servicio se degrada o un dato queda desincronizado, miles de viajeros lo sienten en el mostrador de check-in. Esa conexión directa entre sistemas distribuidos a escala continental y aviones moviéndose en el mundo físico fue lo que me hizo decir que sí.

🛠️ Qué vamos a construir

Me sumo al equipo responsable de una de las plataformas centrales que respalda la información del pasajero y su autogestión en reservas, check-in, lealtad y administración de viajes tanto en web como en móvil.

Manteniendo en reserva los detalles internos de la compañía, el trabajo técnico abarca cinco frentes:

• Servicios en Go orientados a contratos sobre Google Cloud: diseñamos y evolucionamos servicios backend de alto rendimiento con gRPC y Protocol Buffers para que las decenas de equipos consumidores trabajen contra interfaces tipadas, versionadas y con compatibilidad estricta.
• Consistencia fuerte en varios países en simultáneo: pasamos de esquemas fragmentados a una arquitectura relacional distribuida capaz de sostener transacciones ACID y alta disponibilidad en toda la operación regional.
• Pipelines orientados a eventos e historial auditable: transmitimos cambios operacionales hacia almacenes analíticos mediante captura de datos de cambio (CDC), con procesamiento idempotente y un registro que permite reconstruir el estado de un dato en cualquier punto del tiempo.
• Migraciones masivas sin tiempo de inactividad: movemos grandes volúmenes de datos hacia la nueva plataforma en caliente, apoyados en conciliación cuantitativa y cualitativa antes de cada corte de tráfico y despliegues progresivos con feature flags.
• Privacidad y gobierno de datos desde el modelo inicial: integramos la protección de datos personales y las reglas legales de múltiples jurisdicciones directamente en el diseño de las tablas y los flujos del sistema.

🧠 Cómo estudio un sistema grande en las primeras semanas

Cuando entras como ingeniero Senior a una organización grande es muy fácil caer en una trampa común: abrir cincuenta pestañas de documentación, clonar veinte repositorios al azar y encadenar reuniones esperando que el contexto se absorba por ósmosis. Tres días después, en medio de una revisión técnica, la mitad de las siglas se borraron de la cabeza y terminas leyendo el mismo documento cuatro veces en dos semanas.

Quiero entender las razones por las que el sistema actual tiene la forma que tiene antes de proponer el primer cambio. Para lograrlo sin saturarme, organizo mis primeras semanas alrededor de cinco hábitos concretos:

1. La valla de Chesterton y tres mapas a mano

El principio de la valla de Chesterton dice que nunca conviene derribar una cerca sin saber antes por qué la construyeron. En software con años de vuelo, una decisión que parece extraña suele ser la cicatriz de un incidente pasado o de una restricción de negocio que todavía no conoces.

Antes de emitir opiniones técnicas, dedico mis bloques de estudio a trazar por mi cuenta tres mapas:

• Mapa de arquitectura (bocetos C4): mirar diagramas existentes rara vez alcanza. Dibujar desde cero los diagramas de contexto y contenedores en papel o texto plano me obliga a verificar qué entra, qué sale, dónde están los límites de cada servicio y qué pasa cuando falla una dependencia externa.
• Mapa de dominio e invariantes: qué reglas del negocio aéreo son inquebrantables y qué datos no pueden perderse ni desincronizarse jamás. Entender las invariantes del dominio rinde mucho más que memorizar líneas de código.
• Mapa de personas: quién guarda la historia de cada componente, qué equipos consumen nuestros servicios aguas arriba y aguas abajo, y a quién acudir según el tipo de duda.

2. Arqueología de código y una bitácora de hipótesis

Hacer preguntas al equipo es indispensable, y las respuestas mejoran mucho cuando haces el trabajo previo en el código. Para no interrumpir a mis compañeros con dudas que el repositorio puede responder solo, uso herramientas de IA autorizadas en modo de lectura para seguir el rastro de una petición de punta a punta, ubicar puntos de entrada y listar dependencias entre módulos.

Cuando encuentro un comportamiento que sigo sin entender, lo anoto en una bitácora de hipótesis (Question Ledger) antes de llevarlo al chat:

Duda → Qué observé en el código → Mi hipótesis de por qué funciona así → Pregunta concreta para validarla.

Llegar a una sesión de onboarding diciendo “Vi que este flujo maneja los reintentos de esta manera; imagino que se diseñó así por X restricción, ¿voy bien?” cuida el tiempo del equipo y abre conversaciones técnicas mucho más ricas.

3. Notas en Markdown, recuerdo activo y repetición espaciada

Leer documentación da una falsa sensación de dominio: como el texto tiene sentido mientras está abierto en el monitor, parece que ya quedó aprendido. Para fijar ese conocimiento de verdad combino tres prácticas:

• Notas breves en Markdown: mantengo una bóveda en texto plano (Obsidian) donde resumo con mis propias palabras cómo funciona cada pieza del dominio. Si no puedo explicarlo simple en una nota limpia, todavía me falta entenderlo.
• Recuerdo activo (Active Recall): al terminar de leer un diseño o explorar un servicio, cierro la ventana e intento dibujar el flujo de memoria en una hoja en blanco. Los puntos donde me trabo marcan exactamente qué debo repasar.
• Repetición espaciada con Anki (algoritmo FSRS): cada acrónimo del sector aeronáutico, invariante del negocio o contrato clave pasa a una tarjeta breve de pregunta y respuesta o de texto oculto (cloze deletion) en Anki, programada con el algoritmo FSRS. Repasar diez minutos por la mañana me permite dominar en pocas semanas el vocabulario interno que suele tomar meses incorporar por repetición casual.

4. Dos horas sin ruido, menos pantalla y el puente de Hemingway

Trabajar desde Bogotá (UTC-5) con equipos en horario de Santiago de Chile me da un bloque tranquilo a primera hora de la mañana antes de que empiece el ritmo de mensajes del día. Reservo ese rato para lo que pide más concentración: lectura profunda de arquitectura, estudio de sistemas distribuidos y práctica de inglés técnico. Además, para descansar la vista de los monitores retroiluminados, paso la lectura conceptual larga y el bocetado de diagramas a pantallas de tinta electrónica (E-Ink), papel o audio.

Al cerrar la jornada aplico un truco que Ernest Hemingway usaba al escribir sus libros: cortar cuando todavía sabes cómo sigue. Antes de apagar la computadora anoto en tres líneas qué aprendí ese día y dejo escrito el archivo exacto, el diagrama a mitad de camino o la pregunta concreta por la que voy a arrancar a las 07:00 AM del día siguiente. Ese puente elimina la fricción de arranque por la mañana y me mete en tema en dos minutos.

5. Llevar un cambio pequeño a producción pronto

Ningún mapa ni sistema de notas reemplaza el contacto con producción. En paralelo al estudio inicial, mi objetivo es llevar un cambio acotado y seguro a producción lo antes posible. Un ajuste modesto enseña más sobre los pipelines reales de integración continua, la batería de pruebas, los criterios de revisión de código y las alertas del equipo que tres semanas leyendo manuales en silencio.

📡 Lo que viene (y una serie nueva en el blog)

Entrar a una plataforma de esta escala recuerda todo lo que queda por aprender. Durante los próximos meses voy a compartir por aquí las lecciones de ingeniería que vayan saliendo: patrones de consistencia en bases de datos distribuidas, diseño de contratos con gRPC, estrategias de migración en vivo y aprendizajes operando servicios de alto tráfico. Lo interno de la compañía se queda en casa, pero los principios de ingeniería viajan bien.

También voy a publicar una serie de artículos dedicada a mi metodología de estudio, toma de notas y gestión del conocimiento. Llevo tiempo probando y refinando en mi día a día un flujo propio con notas local-first en Markdown, clasificación de baja fricción, repetición espaciada con FSRS, lectura en tinta electrónica y apoyo de IA para aprender más rápido, sacar adelante proyectos personales de software y pensar con claridad lejos del ruido de las pantallas.

✈️ Seguimiento del marco técnico y arquitectura:
Puedes seguir los hitos técnicos públicos y el alcance de esta etapa en mi página de experiencia en LATAM Airlines. Por ahora, el estado más honesto que tengo es el que aparece ahí: los cimientos están listos y la historia recién empieza a escribirse.