✈️ Why I Joined LATAM Airlines and How I Study a New System

This month I joined LATAM Airlines as a Senior Backend Engineer. I am still in those early weeks of learning names, decoding internal acronyms that sound like another language, reading architecture docs, and sketching system diagrams by hand that I will probably redraw three times as the edge cases missing from the docs show up.

Before the daily routine makes everything feel normal, I want to write down three things: why I moved into the airline industry, what kind of distributed systems problems we are solving, and how I structure my study workflow during the first weeks to absorb context fast without burning out.

🛫 From payments and fraud to airline operations

My last few years were spent in fintech, e-commerce, and high-concurrency loyalty systems: real-time point-of-sale fraud engines, centralized authentication platforms, and security infrastructure at companies like Mercado Libre and Leal.

Those environments train you to watch tail latencies (p95/p99), database contention, and transactional integrity. A race condition during a checkout or a points redemption costs money in seconds, so balances have to match to the cent.

An airline introduces a different kind of physical and operational weight. When a passenger is standing at an airport kiosk or in the boarding line with a carry-on, a frozen screen stops a real line of people. Behind a single tap on the web or mobile app, that traveler’s data crosses multiple countries, regulatory frameworks, time zones, and critical systems before the plane pushes back from the gate.

When a service degrades or data falls out of sync, thousands of passengers feel it at the check-in counter. That direct link between continental-scale distributed systems and planes moving in the physical world is what made me say yes.

🛠️ What we are building

I am joining the team responsible for one of the core platforms backing passenger data and self-service flows across booking, check-in, loyalty, and trip management on web and mobile.

Keeping company internals private, the engineering work spans five areas:

• Contract-first Go services on Google Cloud: designing and evolving high-throughput backend services with gRPC and Protocol Buffers so dozens of consuming teams work against typed, versioned interfaces with strict compatibility.
• Strong consistency across multiple countries at once: moving from fragmented storage schemas to a distributed relational architecture capable of holding ACID transactions and high availability across simultaneous regional operations.
• Event-driven pipelines and auditable history: streaming operational changes into analytical stores through change data capture (CDC), with idempotent processing and an audit log that can reconstruct the state of any record over time.
• Zero-downtime mass migrations: moving large data volumes to the new platform on live traffic, backed by quantitative and qualitative reconciliation before every cutover and progressive rollouts behind feature flags.
• Privacy and data governance in the initial model: building personal data protection and multi-jurisdiction legal compliance directly into table schemas and read/write flows from day one.

🧠 How I study a large system in my first weeks

When you join a large organization as a senior engineer, it is easy to fall into a common trap: opening fifty documentation tabs, cloning twenty repositories at random, and sitting through meetings hoping context sticks by osmosis. Three days later, in the middle of a technical review, half the acronyms are gone and you end up reading the same document four times in two weeks.

I want to understand why the current system looks the way it does before proposing my first change. To get there without drowning in context, I organize my first weeks around five practical habits:

1. Chesterton’s fence and three hand-drawn maps

Chesterton’s fence is a reliable rule for legacy software: never tear down a fence until you understand why it was built. In a mature platform, an odd design choice is usually the scar of an old incident or a business constraint you have not met yet.

Before forming technical opinions, I use my study blocks to draw three maps for myself:

• Architecture map (C4 sketches): looking at existing diagrams rarely sticks. Drawing context and container diagrams from scratch on paper or plain text forces me to verify what goes in, what comes out, where service boundaries sit, and what breaks when an external dependency fails.
• Domain and invariants map: which airline business rules can never be broken, and which data can never be lost or fall out of sync. Understanding domain invariants pays off ten times more than memorizing lines of code.
• People map: who holds the historical memory for each component, which teams consume our services upstream and downstream, and who to ask depending on the question.

2. Code archaeology and a hypothesis log

Asking teammates questions is essential, and the answers get much better when you do the groundwork in the repository first. To avoid interrupting the team with questions the code can answer on its own, I use authorized AI tools in read-only mode to trace request flows end to end, locate entry points, and list dependencies across modules.

When I hit behavior that still does not make sense, I log it in a personal Question Ledger before posting in chat:

Doubt → What I saw in the code → My hypothesis on why it works this way → Concrete question to validate it.

Showing up to an onboarding session with “I noticed this flow handles retries this way; my guess is that it was designed around X constraint, am I on the right track?” respects the team’s time and leads to much deeper technical conversations.

3. Markdown notes, active recall, and spaced repetition

Reading documentation creates an illusion of competence: because the page makes sense while you are looking at it, you feel like you learned it. To make context stick, I combine three study habits:

• Plain-text Markdown notes: I keep a local vault (Obsidian) where I distill in my own words how each piece of the domain works. If I cannot explain a flow cleanly in a short note, I do not understand it yet.
• Active recall: after reading an architecture doc or exploring a service, I close the window and try to sketch the flow from memory on a blank sheet. The spots where I get stuck show me exactly what I missed.
• Spaced repetition with Anki (FSRS algorithm): every aviation acronym, domain invariant, or key contract becomes a short question-and-answer or cloze-deletion card in Anki scheduled by the FSRS algorithm. Reviewing those cards for ten minutes in the morning locks in the internal vocabulary in a couple of weeks instead of months of casual exposure.

4. Two quiet morning hours, less screen glare, and Hemingway’s bridge

Working from Bogotá (UTC-5) with teams on Santiago time gives me a quiet window early in the morning before chat notifications pick up. I reserve that block for the heaviest concentration work: deep architecture reading, distributed systems study, and deliberate technical English practice. To save my eyes from backlit monitors during long reading sessions, I move heavy conceptual reading, note review, and diagram sketching to E-Ink screens, paper, or audio.

At the end of the workday I use a habit Ernest Hemingway relied on when writing novels: stop while you still know what comes next. Before closing my laptop, I write three lines on what I learned that day and leave the exact file, half-drawn diagram, or concrete question I will open at 7:00 AM the next morning. That small bridge removes morning startup friction and gets me into flow in two minutes.

5. Ship a small change to production early

No note system or diagram survives first contact with production intact. Alongside all this initial study, my parallel goal is to ship a modest, safe change to production as early as possible. A small pull request teaches you more about real CI pipelines, test suites, code review standards, and team observability than three weeks of reading manuals in silence.

📡 What comes next (and a new blog series)

Joining a platform of this scale is a constant reminder of how much there is to learn. Over the coming months I will share the engineering lessons that come out of this stage: consistency patterns in distributed databases, contract design with gRPC, live migration strategies, and real lessons from operating high-traffic services. Company internals stay in-house, while the engineering principles travel well.

I will also publish a series of articles dedicated to my study, note-taking, and knowledge management methodology. I have been testing and refining a personal workflow in my daily routine that combines local-first Markdown notes, low-friction classification, spaced repetition with FSRS, E-Ink devices, and AI-assisted study to learn complex domains faster, build personal software projects, and keep a clear head without living glued to backlit screens.

✈️ Track the architecture charter & roadmap:
You can follow the public technical milestones and scope of this stage on my LATAM Airlines experience page. For now, the most honest status I have is the one on that page: the foundation is ready and the story is just starting to be written.