Henry Hoang

API Gateway with Kong - Slides

Instructor slide content for Unit 2: configuring Kong API Gateway for routing, authentication, and service management

SLIDE DECK: MODULE 02 - API GATEWAY (KONG) - FULL VERSION

Total Duration: 180 minutes (Concept/Lecture) Audience: Fresher/Employee (Completed Module 01)

Slide 1: Title Page

  • Content:
    • (Company / Training Unit Logo)
    • MODULE 02: API GATEWAY
    • Controlling the Gateway to your Microservice Ecosystem
    • Tool: Kong API Gateway
    • Trainer: (Your Name)
    • Date: (Training Date)
  • Visualization:
    • Professional layout.
    • A key visual of a "checkpoint" or a "conductor" directing an orchestra (the services).
    • The Kong logo is placed in the corner.
  • Instructor Script:
    • "Welcome back, everyone. In Module 01, we successfully broke down our monolith and created our first independent services. But now, we have a new problem: How does the client (Frontend/Mobile) communicate with this 'chaotic mesh' of services safely, efficiently, and with control?"
    • "Module 02 will solve exactly that. We will learn about the API Gateway—the 'gatekeeper' and 'conductor' of our entire system. The tool we'll be using is Kong, one of the most powerful and popular API Gateways available today."

Slide 2: Session Agenda (Updated)

  • Content:
    • AGENDA (180 MINUTES)
    • P1. The Problem: The "Client-to-Service" Mess
    • P2. The Solution: What is an API Gateway?
    • P3. Core Concepts (Routing, Auth, Rate Limit)
    • P4. Intro to Kong API Gateway & Lab Setup
    • P5. Optimization & Pitfalls (Best Practices)
    • P6. Real-world Case Studies (Netflix, Finance)
    • P7. Summary, Q&A & Next Module
  • Visualization:
    • A 7-step timeline. Parts P3 (Concepts), P4 (Kong/Lab), P5 (Best Practices), and P6 (Case Studies) are highlighted as the core focus.
  • Instructor Script:
    • "This is our new and complete agenda. The first four parts focus on the 'Why,' 'What,' and 'How' of configuring Kong."
    • "But the real value comes from Parts 5 and 6. This is where we learn 'How to do it well—meaning the Best Practices to avoid common pitfalls—and 'How it's done in the real world'—meaning the Case Studies of how Netflix and financial companies use gateways. Finally, we'll wrap it all up."

Slide 3: Learning Objectives

  • Content:
    • OBJECTIVES (AFTER THIS MODULE, YOU WILL BE ABLE TO...)
    • 1. Explain: The role and benefits of an API Gateway (offloading services, centralizing security).
    • 2. Distinguish: Define the 3 core concepts: Routing, Authentication, and Rate Limiting.
    • 3. Configure: Use the Kong Admin API to register Services and create Routes for your services.
    • 4. Critique: Identify anti-patterns (like 'Fat Gateway') and apply best practices (like 'Config as Code').
  • Visualization:
    • Use 4 icons: [Icon: Brain (Explain)], [Icon: Fork/Split (Distinguish)], [Icon: Gears (Configure)], [Icon: Critical Thinking/Judge (Critique)].
  • Instructor Script:
    • "This is our upgraded commitment to you. You won't just be able to configure (Objective 3), you must also be able to critique (Objective 4). You need to know why some approaches are wrong, and what the right way to do it in practice is. That is the difference between a 'follower' and a 'designer'."

Slide 4: Module 01 Recap

  • Content:
    • RECAP: WHERE ARE WE?
    • Module 01: We broke down the Monolith using the Strangler Fig Pattern.
    • Result:
      • User Service (FastAPI) running at http://localhost:8000
      • Product Service (FastAPI) running at http://localhost:8001 (upcoming lab)
  • Visualization:
    • A simple diagram: [Service 1 (Port 8000)] and [Service 2 (Port 8001)]. Both are "floating" independently.
  • Instructor Script:
    • "Let's take a look back. In Module 1, we successfully split out the User Service to run on port 8000. And in the upcoming lab, you will split out the Product Service to run on port 8001."
    • "Now, imagine you are a Frontend developer. You have to 'remember' that port 8000 is for Users, 8001 is for Products. What if we have 50 services? You have to memorize 50 ports? And you have to handle CORS in all 50 of those services? This is the next 'pain point'."

Slide 5: P1 - The Problem: The "Client-to-Service" Mess

  • Content:
    • THE PROBLEM: DIRECT COMMUNICATION
    • A Frontend/Mobile (Client) needs to call:
      • User Service (Port 8000) to Login.
      • Product Service (Port 8001) to get products.
      • Order Service (Port 8002) to place an order.
      • Payment Service (Port 8003) for payment...
    • "THE PAIN":
      • Overburdened Client: The client must know the address of every service.
      • Difficult Refactoring: Change a port, split a service -> The Client must be recoded.
      • Distributed Security: Every service must code its own Auth logic.
      • Repetitive Logic: Every service must code its own Rate Limiting, Logging, Caching...

  • Visualization:

    • A "spaghetti" diagram: [Frontend/Mobile] shoots 5-6 arrows to 5-6 different services (User, Product, Order...).
  • Instructor Script:
    • "This is the 'mess' I was talking about. [Point to diagram] When the client talks directly to every service, it creates 4 major 'pain points'."
    • "First, the Frontend/Mobile code becomes extremely complex. Second, the Backend team never dares to refactor, because changing one port will 'break' the mobile app."
    • "And most importantly, [EMPHASIZE] the 'non-functional' requirements. Every service has to write its own Auth code, its own Rate Limiting code. That is a massive waste of resources and a huge security risk. We are repeating code everywhere."

Slide 6: P2 - The Solution: API Gateway

  • Content:
    • THE SOLUTION: API GATEWAY
    • Concept: A single "Facade" that acts as the single entry point for all client requests.
    • It is the "Gatekeeper":
      • The Client only needs to know 1 single address: http://api.mycompany.com
      • The Gateway will delegate (or proxy) requests to the internal services.
    • Benefits:
      • Decoupling: The Client is decoupled from the internal services (their addresses, their number).
      • Centralization: Handle all "Cross-Cutting Concerns" (the repetitive stuff) in one single place.

  • Visualization:

    • A "clean" diagram: [Frontend/Mobile] shoots only 1 arrow to [API GATEWAY].
    • The [API GATEWAY] then shoots arrows to the 5-6 services (User, Product, Order...) inside a "trusted zone" (the internal system).
  • Instructor Script:
    • "And here is the solution. Instead of letting the client run all over the place, we set up a single 'gatekeeper,' called the API Gateway. [Point to diagram]"
    • "From now on, the Frontend only calls one address, for example, api.mycompany.com. Every request goes through this 'gate.' The 'gate' will examine the request (e.g., is it for /users or /products?) and automatically 'route' that request to the corresponding internal service."
    • "What's the benefit? The client is simplified. And most importantly: All that repetitive logic (Auth, Rate Limit, Logging...) is now handled centrally at the 'gate'."

Slide 7: P3 - Core Concepts

  • Content:
    • PART 3
    • CORE GATEWAY CONCEPTS
    • The 3 main responsibilities of the "Gatekeeper"
    • 1. Routing
    • 2. Authentication
    • 3. Rate Limiting
  • Visualization:
    • Title slide for Part 3.
    • An image of a "security guard" with 3 icons: [Icon: Map/Compass (Routing)], [Icon: ID Card/Key (Auth)], [Icon: Clock/Counter (Rate Limit)].
  • Instructor Script:
    • "So what does this 'gatekeeper' do? It has three main responsibilities, and we'll go through each one."

Slide 8: Concept #1: Routing

  • Content:
    • 1. ROUTING
    • What is it? The ability to "steer" an incoming request to the correct internal service, based on rules you define.
    • Example (Rule):
      • "IF an incoming request has the path /api/v1/users -> Steer it to the User Service (at http://localhost:8000)."
      • "IF an incoming request has the path /api/v1/products -> Steer it to the Product Service (at http://localhost:8001)."
    • Benefit: The client doesn't need to know what port your service runs on. You can change port 8000 -> 9000, and the client will never know (you just update the rule on the Gateway).

  • Visualization:

    • Diagram:
      • Request: /users -> [GATEWAY] -> [User Service (port 8000)]
      • Request: /products -> [GATEWAY] -> [Product Service (port 8001)]
  • Instructor Script:
    • "The first and most basic job is 'giving directions' (Routing). The Gateway reads the incoming request, for example, GET /api/v1/users."
    • "It checks its 'rulebook' and sees: 'Ah, the /users path must go to the User Service house at port 8000.' And so, it 'forwards' the request there."
    • "This is extremely powerful. Tomorrow, the User team wants to change to port 9000? No problem. They just tell the 'gatekeeper' (Gateway) to update the 'rulebook'. The Frontend/Mobile side doesn't change a single line of code."

Slide 9: Concept #2: Authentication (Auth)

  • Content:
    • 2. AUTHENTICATION (Auth)
    • What is it? The process of verifying "Who are you?" before allowing access.
    • How it works (Centralized):
      1. Client sends a request with a "ticket" (e.g., API Key, JWT Token) to the Gateway.
      2. The Gateway (not the Service) validates this "ticket."
      3. If "ticket" is valid -> Allow the request to pass to the internal service.
      4. If "ticket" is invalid -> The Gateway blocks it immediately (Returns 401 Unauthorized).
    • Benefit: The services (User, Product...) no longer need to write auth code. They trust that every request that gets to them is already "clean."

  • Visualization:

    • Diagram:
      • Request + (Invalid Token) -> [GATEWAY] -> [STOP! (401 Error)]
      • Request + (Valid Token) -> [GATEWAY] -> [Pass] -> [User Service]
  • Instructor Script:
    • "The 'gatekeeper' will ask: 'Where is your ticket?' This is Authentication."
    • "Instead of 50 services each having its own 'security guard' to check tickets, we centralize one 'security checkpoint' at the API Gateway."
    • "The Gateway looks at the 'ticket' (JWT Token, API Key...). If it's fake, it blocks the request immediately, returning a 401. That request never touches your internal service."
    • "The benefit? [EMPHASIZE] All 50 of your services can now be 'naive'. They don't need to worry about Auth. They just focus on business logic. The security burden has been offloaded to the Gateway."

Slide 10: Concept #3: Rate Limiting

  • Content:
    • 3. RATE LIMITING
    • What is it? The process of controlling the "Frequency" (number) of requests from a single client.
    • Why?
      • To prevent DDoS attacks (1 client sending 1 million requests/sec).
      • To ensure "fair use" for all other clients.
      • To manage costs (if your API is a product).
    • How it works (Centralized):
      • The Gateway counts requests from each client (e.g., by IP or API Key).
      • Rule: "Client A is only allowed 100 requests / minute."
      • If Client A makes request #101 -> The Gateway blocks it (Returns 429 Too Many Requests).

  • Visualization:

    • A "counter" on the Gateway.
    • Client A (100 requests/min) -> [GATEWAY] -> [Pass]
    • Client A (Request #101) -> [GATEWAY] -> [STOP! (429 Error)]
  • Instructor Script:
    • "Finally, the 'gatekeeper' controls 'frequency'. You have a valid ticket, but you can't 'go in and out' a million times a second."
    • "This is Rate Limiting. It protects your system from being 'knocked over' by a DDoS attack or a 'badly-coded client' in an infinite loop."
    • "The Gateway will count. 'Ah, this IP has already called 100 times this minute. Request #101? Blocked!'. And it returns a 429 'Too Many Requests'."
    • "Once again, your internal services don't need to worry about this. The Gateway handles it."

Slide 11: Other Benefits (Cross-Cutting Concerns)

  • Content:
    • THE GATEWAY CAN DO EVEN MORE...
    • Anything you see repeated in your services, "offload" it to the Gateway:
    • Centralized Logging: Log all requests/responses at a single point. (We'll learn in Module 5)
    • Caching: Cache responses (e.g., GET /products) at the Gateway to reduce load. (We'll learn in Module 6)
    • Response Transformation: "Translate" a service's response (e.g., XML) into a format the client wants (e.g., JSON).
    • SSL Termination: Handle HTTPS at the Gateway; internal services can just run HTTP for simplicity.
  • Visualization:
    • A "control panel" (dashboard) with many toggles: [Logging], [Caching], [SSL], [Transform].
  • Instructor Script:
    • "Routing, Auth, and Rate Limiting are the big three. But the real power of a Gateway is its ability to handle all 'cross-cutting concerns'."
    • "You want centralized logging? Do it at the Gateway—we'll cover this in Module 5. You want caching? Do it at the Gateway—we'll learn this with Redis in Module 6. You want to handle HTTPS? Let the Gateway do it. Your internal services just need to do one thing: Business Logic. This is 'System Thinking'—a clear separation of concerns."

Slide 12: P4 - Intro to Kong API Gateway

  • Content:
    • PART 4
    • INTRO TO KONG API GATEWAY
    • What is Kong?
      • A blazing-fast, open-source API Gateway (built on Nginx).
      • Cloud-Native: Designed for Docker, Kubernetes.
      • Plugin-based: Kong's power comes from "Plugins."
        • Need Auth? enable('jwt-auth').
        • Need Rate Limit? enable('rate-limiting').
    • Installation: We will use Docker Compose.
    • Interaction: Kong (free version) has no UI. We will "command" it via its Admin API (Port 8001).

  • Visualization:

    • Large, clear Kong logo.
    • Simple diagram: [Client] -> [Kong Proxy (Port 8000)].
    • To the side: [Admin (You)] -> [Kong Admin API (Port 8001)].
  • Instructor Script:
    • "Okay, enough theory. We will be using Kong. Kong is one of the most popular gateways, built on Nginx, so it's blazing fast."
    • "Kong's philosophy is 'Plugins.' Every feature (Auth, Rate Limit...) is a plugin. You need something, you 'enable' it."
    • "One [CRITICALLY IMPORTANT] point: Kong (the free, open-source version) does not have a point-and-click UI. We are going to work like real engineers: We will 'command' it by making API calls to its 'Admin API,' which, by default, is on port 8001."

Slide 13: Kong's Core Components

  • Content:
    • HOW DOES KONG "THINK"?
    • You must define two main things for Kong to work:
    • 1. Service:
      • What: An entity that represents one of your upstream (internal) services.
      • Example: "I have a service named user-service running at http://localhost:8000".
    • 2. Route:
      • What: A rule that "steers" traffic to a Service.
      • Example: "IF an incoming request has the path /api/users (Rule) -> forward it to the user-service (Service)."
    • (Advanced):
      • Consumer: Represents a client (a user/app) that consumes your API.
      • Plugin: Attaches features (Auth, Rate Limit) to a Service, Route, or Consumer.
  • Visualization:
    • A relationship diagram:
      • Request (path: /users) -> [Route (Rule)] -> [Service (Upstream: port 8000)]
  • Instructor Script:
    • "To configure Kong, you have to learn its 'language.' It's very simple, just two main concepts."
    • "One, 'Service.' This is the 'destination.' You must 'register' with Kong: 'Hey Kong, I have a service named user-service, and its address is localhost:8000'."
    • "Two, 'Route.' This is the 'rule of the road.' You tell Kong: 'Hey Kong, IF you see any request with the path /api/users, YOU MUST send it to the user-service I just registered'."
    • "That's it. Service is the 'destination,' Route is 'the path' to get there. We'll practice this right now."

Slide 14: P4 (Continued) - Lab Prep: Task 1 & 2

  • Content:
    • PART 4 (CONTINUED)
    • IMPLEMENTATION LAB (TASK 1 & 2)
    • Using Kong as our "Gatekeeper"
  • Visualization:
    • Title slide. Icons: [Icon: Keyboard], [Icon: Code], [Icon: Terminal].
  • Instructor Script:
    • "Now for the most important part: the hands-on lab. Your mission is to finish Task 1 (splitting the User service), start Task 2 (splitting the Product service), and then put Kong in front as the 'gatekeeper' for both."

Slide 15: Lab - Architecture (Before & After)

  • Content:
    • CURRENT STATE (BEFORE)
    • [Client] -> http://localhost:8000 (User Service)
    • [Client] -> http://localhost:8001 (Product Service)
    • (Chaotic, client knows 2 addresses)
    • TARGET STATE (AFTER)
    • [Client] -> http://localhost:80 (KONG PROXY)
      • /api/users -> (Kong Route) -> User Service (8000)
      • /api/products -> (Kong Route) -> Product Service (8001)
    • (Client only knows 1 single address: Kong)
  • Visualization:
    • Two "Before" and "After" diagrams side-by-side.
    • "Before": The "spaghetti" diagram (from Slide 5).
    • "After": The "clean" diagram (from Slide 6), with the path rules written on the arrows.
  • Instructor Script:
    • "This is our lab's objective. [Point to 'Before'] Currently, the client is calling 'all over the place' to ports 8000 and 8001."
    • "[Point to 'After'] Our goal is: The client will only call one single port (e.g., port 80), which is Kong's proxy port. Then, we will configure Kong to automatically 'steer' traffic for /api/users to port 8000 and /api/products to port 8001."

Slide 16: Lab - Guide (Demo & Hands-on)

  • Content:
    • LAB GUIDE (TASK 1 & 2)
    • Task 1 (Finish): Complete the User Service refactor.
    • Task 2 (Start): Begin the Product Service refactor (similar to User Service).
    • KONG SETUP (DEMO):
      1. Trainer provides the docker-compose.yml for Kong (Kong & DB).
      2. Run docker-compose up -d.
    • KONG CONFIGURATION (LAB):
      1. Register user-service:
        • POST http://localhost:8001/services
        • (Body: { "name": "user-service", "url": "http://host.docker.internal:8000" })
      2. Create route for user-service:
        • POST http://localhost:8001/services/user-service/routes
        • (Body: { "paths": ["/api/users"] })
      3. Repeat: Do the same for product-service (path /api/products).
      4. Verify: Use Postman to call Kong at http://localhost:80/api/users and see the result.
  • Visualization:
    • Sample code snippets (curl/http request) for the Admin API.
    • A note: Use host.docker.internal so the Kong Docker container can "see" the services running on your localhost (the host machine).
  • Instructor Script:
    • "Here are the steps. Tasks 1 and 2 are for you to complete the service code (like in Module 1)."
    • "Next, I will quickly demo how to launch Kong using Docker Compose. This file will be provided to you."
    • "Your main task is here [point to 'KONG CONFIGURATION']. You will use Postman (or curl) to 'command' Kong. Command 1: 'POST' to port 8001 (Admin API) to create a new Service named user-service."
    • "Command 2: 'POST' to that service to create a new Route, attaching it to the path /api/users. You will repeat this for the product-service."
    • "Finally, you will 'test' by calling port 80 (Kong's proxy port). If everything is correct, Kong will automatically forward your request to your service."

Slide 17: P5 - Optimization & Pitfalls (Best Practices)

  • Content:
    • PART 5
    • OPTIMIZATION & PITFALLS (BEST PRACTICES)
    • How to stop the "Gatekeeper" from becoming a "Dictator"
    • 1. PITFALL: "FAT GATEWAY" ANTI-PATTERN
      • Problem: Greedily stuffing Business Logic into the Gateway (e.g., calculating prices, complex data aggregation...).
      • Consequence: Your Gateway becomes a Monolith 2.0—hard to maintain, hard to scale, and violates Bounded Context (Module 1).
      • Rule: The Gateway should ONLY handle Infrastructure/Cross-Cutting Logic (Auth, Route, Log, Rate Limit), NOT Business Logic.
    • 2. Best Practice: Config as Code
      • Problem: Configuring a Gateway by hand (using curl/Postman) is risky, not trackable, and error-prone in Production.
      • Solution: Store your Kong configuration (Services, Routes) as files (YAML/JSON) and manage them in Git. Use tools like deck (for Kong) or Terraform to "apply" the configuration automatically (GitOps).
    • 3. Best Practice: Monitor the "Gatekeeper"
      • The Gateway is a Single Point of Failure (SPOF).
      • If the Gateway goes down -> Your ENTIRE system goes down.
      • Requirement: The Gateway must be monitored 24/7 (Logs, Metrics, Traces)—we will learn this in detail in Module 5 (Observability).
  • Visualization:
    • A diagram of a "bloated" red Gateway "reaching into" the logic of services, compared to a "lean" green Gateway that only "steers" traffic.
    • Icon [Icon: Git logo] for "Config as Code".
    • Icon [Icon: Grafana/Prometheus dashboard] for "Monitor".
  • Instructor Script:
    • "Okay, you've all finished the lab. But before we finish, this is the part where the veterans pass down their 'hard-won' experience. These are the pitfalls that 90% of teams fall into."
    • "[EMPHASIZE] The biggest pitfall: The 'Fat Gateway.' The line between 'helping' and 'doing their job for them' is very thin. You see the Gateway is 'convenient,' so you code the 'price calculation' logic right into it. DON'T DO THAT. That is 'business logic'; it belongs in the Product Service."
    • "When your Gateway knows too much about the business, it becomes a 'Monolith 2.0.' And we are back to square one. Remember: The Gateway handles 'infrastructure' (like Auth, Route), the Services handle 'business'."
    • "Second, never 'point-and-click' or 'curl' by hand to configure Production. Use 'Config as Code.' All Gateway configuration must be stored in Git, peer-reviewed, and deployed automatically. Treat it as code."
    • "Finally, the Gateway is your 'critical chokepoint.' If it goes down, the entire company 'stops breathing.' Therefore, it must be the #1 priority for monitoring, which we'll learn how to do in Module 5."

Slide 18: P6 - Real-world Case Studies

  • Content:
    • PART 6
    • REAL-WORLD CASE STUDIES
    • Case Study 1: Netflix (Zuul/Spring Cloud Gateway)
      • Problem: Billions of requests per day from thousands of different device types (Smart TV, iPhone, Web, Android, PS5...).
      • Need: Each device needs a different "payload." (e.g., TV needs 4K images, phone only needs HD; TV needs 50 movies, phone only needs 10).
      • Solution: Backend for Frontend (BFF) Pattern
        • Netflix doesn't use one "generic" Gateway.
        • They use the Gateway as an "Adapter" layer. There is a separate "Gateway" (or script on the Gateway) for Web, another for iPhone...
        • This "BFF" Gateway calls 3-4 internal services (User, Movie, Rating) then aggregates and transforms the data into the exact format that specific client needs.
    • Case Study 2: Kong (Financial Enterprise)
      • Problem: Need to provide APIs to third-party partners while ensuring Security and controlling Cost.
      • Solution: Use Kong as a "toll booth."
        • Auth: Issue API Keys (using Consumers) to each partner.
        • Rate Limiting: Apply a "Basic" tier (100 requests/min) and a "Premium" tier (10,000 requests/min) to different partners.
        • Logging: Log every request for billing and auditing purposes.
  • Visualization:
    • Diagram showing [iPhone] -> [BFF for iPhone] and [Web] -> [BFF for Web]. Both BFFs then call the internal services.
    • Diagram of Kong "metering" requests from 3 partners (A, B, C) with different Rate Limit tiers.
  • Instructor Script:
    • "Now let's see how two 'giants' use gateways. First, Netflix, the masters of microservices."
    • "Their problem is 'multi-device.' [Point to BFF diagram] They realized a 'one-size-fits-all' Gateway isn't enough. The Web team wants data in format A, the Mobile (iPhone) team wants it in format B."
    • "Their solution is the 'Backend for Frontend' (BFF) pattern. They create a 'mini-Gateway' for each client type. This BFF acts as a 'servant,' running around to 3-4 internal services, gathering the data, and shaping it into the perfect response that client needs. It's an extremely effective advanced pattern."
    • "The second case study is more practical with Kong: A financial company. They use Kong as a 'toll booth.' [Point to Kong diagram] They issue API Keys (Consumers), then use the 'Rate Limiting' plugin to 'sell' API tiers. Partner A pays $1000/month for 10,000 requests/min. Partner B (free) only gets 100. All of this logic is handled at Kong; the internal services don't even know it's happening."

Slide 19: P7 - Module 2 Summary (NEW)

  • Content:
    • MODULE 2 SUMMARY
      1. The API Gateway is a "single entry point" to Centralize (Auth, Rate Limit...) and Decouple (Routing).
      1. Configuring Kong = Defining a Service (Destination) and a Route (Path).
      1. Pitfall: Beware the "Fat Gateway"—Don't stuff business logic into the Gateway.
      1. Optimization: Always use "Config as Code" (Git) and Monitor your Gateway 24/7.
      1. Advanced: Use Gateways for patterns like "BFF" (Netflix) or "Billing" (Finance).
  • Visualization:
    • 5 summary bullet points. The new items (3, 4, 5) are highlighted.
  • Instructor Script:
    • "Here are the 5 things I want you to 'take home' today. 1 and 2 are 'the basics.' But 3, 4, and 5 are what distinguish an 'expert.' Knowing where the 'pitfalls' are, how to 'optimize,' and how to 'apply' it to real-world problems."

Slide 20: P7 - Q&A (NEW)

  • Content:
    • Q & A
    • Questions & Answers
  • Visualization:
    • A clean, minimal slide. Just the large letters "Q&A".
  • Instructor Script:
    • "Thank you. We now have time for Q&A. Please, feel free to ask your questions."

Slide 21: Thank You & Next Module (Updated)

  • Content:
    • THANK YOU!
    • (Your Contact Info: Email, LinkedIn, etc.)
    • COMING UP (MODULE 3):
    • Module 3: Async Communication (RabbitMQ)
    • We've learned to "call" each other (Sync). Now, we'll learn to "send messages" (Async).
  • Visualization:
    • A "teaser" for Module 3.
    • The RabbitMQ logo.
  • Instructor Script:
    • "Thank you all for your active participation. In Modules 1 and 2, we built services and allowed clients to 'call' them (this is 'synchronous' communication)."
    • "In Module 3, we will learn a completely different style of communication: 'Asynchronous'. Instead of 'making a phone call' (and waiting), we will learn to 'send a text message' (and do other things). This is the key to building truly scalable and fault-tolerant systems."

Microservices Fundamentals & Refactoring - Slides

Instructor slide content for Unit 1: transitioning from monolith to microservices, core principles, and refactoring strategies

Asynchronous Communication with RabbitMQ - Slides

Instructor slide content for Unit 3: building production-ready async messaging with RabbitMQ, including durable queues and manual ACKs

On this page

SLIDE DECK: MODULE 02 - API GATEWAY (KONG) - FULL VERSIONVisualization:Visualization:Visualization:Visualization:Visualization:Visualization: