Free lesson · Mastering SQL
Meet Emeka - Lagos to Netflix
Alex: Before we get into actual SQL - who are you? I know you work at Netflix. But I want to understand the full story. How did you end up building data systems at one of the biggest companies on the planet?
Emeka: I appreciate you asking. And I am going to tell you the real version, not the polished conference-talk version, because I think the real version is more useful to you.
I grew up in Lagos, Nigeria. If you are not familiar with Lagos, it is one of the largest cities in Africa - over twenty million people, intense energy, incredible hustle, and in the early 2000s when I was growing up, very limited access to computers and internet. My first computer was second-hand. I was fourteen. And the compiler I used to teach myself Pascal was pirated, because buying a licensed development tool in Lagos at that time was not something my family could afford.
I want you to sit with that for a second, because wherever you are starting from, I promise you I started further back. No computer science degree yet. No mentors. No Stack Overflow - I barely had consistent internet. Just a fourteen-year-old kid with a used computer, a pirated Pascal compiler, and the idea that maybe, somehow, telling a machine what to do could become a career.
Alex: That is a pretty different starting point from what I usually hear about engineers at Netflix.
Emeka: That is exactly why I am telling you. The tech industry has a mythology around its engineers - like we all came out of Stanford with a MacBook and an internship at Google. Some did. I did not. And if you did not either, I want you to know that the person teaching you this course understands what it feels like to learn with limited resources, limited guidance, and no clear path in front of you.
The Andela Fellowship - Where Everything Changed
I kept coding through secondary school and into university - B.Sc. Computer Science at the University of Lagos. I was decent. I could build things. But I was learning in a bubble. I did not know what "production-grade engineering" meant. I did not know what code review was, or deployment pipelines, or distributed systems. I knew how to write programs that ran on my machine. That is very different from knowing how to build software that runs at scale.
In 2015, something changed. Andela - an organization that trains software engineers in Africa and connects them with global technology companies - opened their inaugural fellowship in Lagos. I got into the first cohort.
Alex: What did Andela teach you that university did not?
Emeka: Andela did not teach me to code. I could already code. Andela taught me to engineer. The difference is massive.
Coding is writing a program that works on your laptop. Engineering is writing a program that works when a million people use it at the same time, at three in the morning, when the database is under load and the network is flaky and someone just deployed a bad config change.
At Andela, I worked with mentors who had built systems at global scale. For the first time, I was doing code reviews. For the first time, I was writing tests. For the first time, I was thinking about what happens when my code fails - not just what happens when it succeeds. And for the first time, I was working with SQL in a way that went beyond classroom exercises. I was querying production databases. I was writing queries that mattered - queries whose results drove actual business decisions.
That fellowship was nine months long. It was the most compressed learning experience of my life. And it opened a door that I did not even know existed.
Paystack - Building From the Ground Floor
After Andela, I joined Paystack - one of the earliest and most important fintech companies in Africa. When I joined, Paystack was still early-stage. Small team, high pressure, real money moving through the system.
Alex: What did you do there?
Emeka: I was a software engineer, but at an early-stage company that title means everything. I wrote backend services. I wrote SQL queries that reconciled transactions across payment processors. I built dashboards that showed the finance team exactly how much money had moved through the system that day, with breakdowns by merchant, by payment method, by time window.
This is where SQL became personal for me. Not academic. Not theoretical. I was writing queries where if the answer was wrong, actual money would be unaccounted for. A SUM that was off by one transaction was not a test failure - it was a business problem that someone would call me about.
Two things happened at Paystack that shaped how I teach this course.
First, I learned that SQL is not just a query language. It is a thinking language. When you write a query, you are expressing a question in a precise, structured form. "Show me all transactions from last month where the payment method was mobile money and the amount was over ten thousand naira, grouped by merchant, sorted by total volume descending." That sentence is SQL. The code just formalizes it. Once I saw that, SQL stopped being a syntax exercise and became a way of reasoning about data.
Second, I learned that production SQL is nothing like tutorial SQL. Tutorial SQL runs against a table with fifty rows and returns instantly. Production SQL runs against a table with fifty million rows and might take twelve minutes if you write it carelessly - or twelve milliseconds if you write it with intention. The difference is not talent. It is knowledge. Specifically, knowledge about indexes, query plans, and how databases actually work underneath the abstraction layer. That knowledge is what this course teaches in Modules 10 through 12, and it is knowledge I earned the hard way at Paystack, at 2 AM, watching a reconciliation query crawl while the finance team waited.
Booking.com - Where Scale Got Real
From Paystack, I moved to Booking.com in Amsterdam. And scale changed from "significant" to "staggering."
graph LR
subgraph Paystack["Paystack (Lagos)"]
P1["Thousands of<br/>transactions/day"]
P2["Small team"]
P3["SQL on single database"]
end
subgraph Booking["Booking.com (Amsterdam)"]
B1["1.5 million<br/>bookings/day"]
B2["Hundreds of engineers"]
B3["Distributed data systems"]
end
subgraph Netflix["Netflix (Los Gatos)"]
N1["8+ billion<br/>events/day"]
N2["Global data platform"]
N3["Real-time streaming SQL"]
end
Paystack --> Booking --> Netflix
style Paystack fill:#6366f1,color:#fff
style Booking fill:#8b5cf6,color:#fff
style Netflix fill:#f59e0b,color:#000
This diagram shows three boxes representing Emeka's career progression, arranged left to right. Paystack in Lagos handled thousands of transactions per day with a small team and SQL on a single database. Booking.com in Amsterdam handled 1.5 million bookings per day with hundreds of engineers and distributed data systems. Netflix in Los Gatos handles over eight billion events per day with a global data platform and real-time streaming SQL. Arrows show the progression from each company to the next.
Alex: 1.5 million bookings a day. That is real scale.
Emeka: And every one of those bookings generated data. Price data, availability data, user behavior data, search ranking data, review data. At Booking.com, I spent five years building and maintaining the data infrastructure that made sense of all of it.
This is where I learned about the topics we cover in the later modules of this course. Data warehousing. Columnar storage. Star schemas and dimensional modeling. Query optimization at a level where shaving 200 milliseconds off a query mattered because that query ran a hundred thousand times a day.
One story sticks with me. We had a reporting query that ran every morning at 6 AM to generate the daily revenue summary for leadership. It had been running for eight minutes, which was fine - until our data volume grew and one morning it ran for forty-five minutes, overlapped with the next scheduled job, and cascaded into a chain of failures that delayed every downstream dashboard for the entire European market. The fix was not magic. It was a composite index, a rewrite of a correlated subquery into a window function, and a partitioning strategy on the bookings table. Total code change: about fifteen lines of SQL. Time savings: from forty-five minutes to ninety seconds. That experience is why I teach Module 10 the way I do - not as abstract theory about indexes, but as the difference between a system that works and a system that fails in front of the people who run the company.
I also learned something that changed how I think about SQL at a fundamental level. At Paystack, SQL was a tool - I used it to answer questions about data. At Booking.com, SQL was an architecture. The entire analytics stack was built around SQL as the interface layer. Data engineers wrote SQL transformations. Analysts wrote SQL reports. Machine learning engineers wrote SQL feature pipelines. The language was the same. The scale was wildly different.
That is why this course has a module called "SQL at Scale" that no other SQL course offers. Because SQL at the scale of Booking.com or Netflix is a different discipline than SQL on a single PostgreSQL instance, and if you are interviewing for a data engineering or infrastructure role, you need to understand the difference.
Alex: How did you get from Booking.com to Netflix?
Emeka: Netflix reached out. By that point I had five years of production data engineering at Booking.com - building systems that handled 1.5 million bookings per day, managing data pipelines at European scale. I went through seven interview rounds in Los Gatos. The process was intense. But the experience I had built - at Paystack, at Booking.com, and before all of that in Lagos teaching myself on a pirated compiler - that experience was exactly what the role required.
Netflix - What I Do Now
Today, I am a Senior Software Engineer on Netflix's Data Platform team. My focus is real-time event streaming - the systems that ingest, process, and deliver over eight billion viewing events every single day.
Alex: Eight billion. Can you put that in perspective?
Emeka: Here is one way to think about it. Every time someone on Netflix presses play, pauses, rewinds, fast-forwards, rates a show, adds something to their list, scrolls past a title, hovers over a thumbnail - each of those interactions generates an event. That event is captured, sent to our data platform, processed in real time, and used for everything from personalized recommendations to infrastructure monitoring to business reporting.
Eight billion of those events. Every day. And the platform I help run processes them within seconds, not hours.
When people ask me what I do every day, the honest answer is: I write SQL, I write code that generates SQL, and I design the systems that SQL runs on. On a typical day, I might write a Flink SQL job to detect unusual viewing patterns in real time, debug why a batch pipeline's aggregation query is producing different numbers than the streaming pipeline for the same metric, review a colleague's query plan to figure out why their Iceberg table scan is reading twice as much data as expected, or design the schema for a new event type that the recommendations team needs to consume.
SQL is not something I use occasionally. It is the primary interface through which I interact with data at Netflix scale. And the distance between writing SQL that works on a textbook example and writing SQL that works at this scale - that distance is exactly what this course bridges.
The technology stack includes Apache Kafka for event streaming, Apache Flink for real-time processing (including Flink SQL - SQL that runs on unbounded data streams), and Apache Iceberg for large-scale data lake management. If those names mean nothing to you right now, that is fine. We cover streaming SQL in Module 12. What matters right now is this: the person teaching you SQL uses SQL every single day, at a scale that most engineers will never encounter, on systems that serve over two hundred million subscribers worldwide.
Why This Matters for How I Teach
Alex: I appreciate the story. But honestly - does it change how you teach SQL?
Emeka: Yes. In three specific ways.
First, I know what it feels like to start from zero. I did not grow up with a computer lab and AP Computer Science. I grew up in Lagos with a pirated compiler. When I explain what a relational database is in Module 1, I remember what it felt like to not know. When I explain three-valued logic, I remember the exact moment NULLs stopped being confusing. I teach from that memory, not from a textbook.
Second, I know what SQL looks like at scale. Most SQL instructors teach you syntax. I teach you syntax, and then I tell you what happens to that syntax when the table has a billion rows. That is not a hypothetical for me - it is Tuesday. When I tell you that OFFSET pagination breaks at scale, it is because I have watched it break. When I tell you to use keyset pagination instead, it is because that is what we use at Netflix. This production lens is woven into every module, not bolted on at the end.
Third, I have sat in the interview chair. I have been through seven rounds at Netflix. I have been through the Booking.com loop. I have faced SQL questions under time pressure, with an interviewer watching, and I know the difference between knowing SQL and performing SQL under pressure. Module 16 is built from that experience - not from theory about what interviews are like, but from living through them.
Important: The teaching philosophy of this course:
I teach SQL the way I wish someone had taught me - starting from genuine zero, building intuition before syntax, connecting every concept to real production systems, and preparing you specifically for the interview pressure that makes talented engineers freeze.
If you can follow a conversation, you can learn SQL from this course. I will handle the rest.
About AlgoInsight and the Team Behind This Platform
I am not doing this alone. AlgoInsight was built by seven engineers who collectively have been rejected by FAANG companies 58 times before eventually getting in. Today we work at Google, Meta, Amazon, Microsoft, Apple, and Netflix.
I handle the data infrastructure and analytics side of the platform. My co-founder Brandon Carter, a Principal Engineer at Amazon who has conducted over 300 interviews as an Amazon Bar Raiser, built the System Design curriculum. Deepika Nair, Staff Engineer at Meta's AI Infrastructure team, built the AI and ML tracks. Each of us owns the part of the platform that matches our actual expertise.
This SQL course is mine. It is the course I would have wanted when I was sitting in Lagos, when I was at Paystack writing my first production query, when I was at Booking.com learning what scale actually means, and when I was preparing for seven rounds at Netflix. It is the course I am building for you because I remember being you.
Alex: Alright. I trust the source. Let us start learning SQL.
Emeka: One more stop before we write our first query. The next lesson is about SQL dialects - because SQL is not one language, it is a family of dialects, and the differences will trip you up if you do not see them coming. Then we move into Module 1 and you get your hands dirty.
Let us go.
Tip: Your next step: Move on to the next topic - A Note on SQL Dialects - where we cover why a query that works in PostgreSQL might break in MySQL, and how this course handles dialect differences throughout.