📖 26 min read

SLIDE DECK: MICROSERVICE FUNDAMENTAL (MODULE 1)#

Total Duration: 4 hours Audience: Fresher (with knowledge of 1 web framework), Employee (Up-skill/Re-skill)

Slide 1: Title Page

  • Content:

    • (Company / Training Unit Logo)

    • MODULE 1: MICROSERVICE FUNDAMENTAL

    • THE STRATEGY OF BREAKING THE MONOLITH

    • Trainer: (Your Name)

    • Date: (Training Date)

  • Visualization:

    • Clean, professional layout.

    • A key visual representing the “breakdown” of one large cube (Monolith) into multiple smaller cubes (Microservices) flying apart.

  • Instructor Script:

    • “Welcome, everyone, to Module 1: Microservice Fundamental. I am (Your Name), and over the next 4 hours, we will dissect one of the hottest, most misunderstood, yet most powerful topics in modern software architecture.”

    • “We won’t just learn ‘What is a microservice.’ We will learn ‘WHY’ it exists, ‘WHEN’ to use it, and most importantly, ‘HOW’ to start migrating from a traditional Monolithic architecture. My goal is that after today, you will be able to think like an architect, not just a developer.”

Slide 2: Session Agenda

  • Content:

    • AGENDA (4 HOURS)

    • P1. Architectural Context (Monolith vs. Microservice)

    • P2. Design Principles (DDD & Database)

    • P3. Implementation Strategy (Strangler Fig Pattern)

    • P4. Implementation Lab (Demo & Hands-on)

    • P5. Optimization & Critique (Best Practices & Anti-Patterns)

    • P6. Real-world Case Study (Case Study: Uber)

    • P7. Assessment & Reinforcement (Quiz & Homework)

  • Visualization:

    • A horizontal timeline or 7-step diagram. Each part is a “station.” Part 4 (Lab) is highlighted in a different color to emphasize “hands-on.”

  • Instructor Script:

    • “This is our 7-part agenda. We’ll start with the core theory in Parts 1 and 2, learn the strategy in Part 3. After that, we will ‘roll up our sleeves’ for real coding in Part 4.”

    • “But what I want you to pay close attention to is Part 5, where we will ‘critique’ the very idea of microservices. We’ll finish by connecting it to reality with a massive case study before we check our knowledge.”

Slide 3: Learning Objectives

  • Content:

    • OBJECTIVES (AFTER THIS MODULE, YOU WILL BE ABLE TO
)

    • 1. Distinguish: Clearly articulate the pros and cons of Monolith vs. Microservice.

    • 2. Identify: Explain the “Bounded Context” concept for service decomposition.

    • 3. Explain: Defend the “Database per Service” principle and understand why a shared DB is an “anti-pattern.”

    • 4. Strategize: Describe and apply the “Strangler Fig Pattern” to refactor a Monolithic application.

  • Visualization:

    • Use 4 strong icons corresponding to the 4 verbs: [Icon: Scales/Balance], [Icon: Radar/Eye], [Icon: Brain], [Icon: Map/Strategy].

  • Instructor Script:

    • “This is my commitment to you. This isn’t a high-level overview. By the end of these 4 hours, you must be able to do these 4 things. Especially points 3 and 4. You must be able to explain ‘why not’ and strategize ‘how to’—that is the difference between a Junior and a Senior.”

Slide 4: Requirements & Handover (Internal)

  • Content:

    • FOR AN EFFECTIVE SESSION

    • Pre-requisites:

      • Basic knowledge of Python & REST APIs.

      • Experience with 1 Web Framework (Django/Flask
).

      • Installed: Python 3.9+, Docker Desktop, Nginx, VS Code.

    • Handover Package (Internal Note):

      • This guide is sent to the TO (Training Officer) to prepare the Lab environment.

      • Trainer’s Notes (teaching guide) are saved on SharePoint for other Trainers.

  • Visualization:

    • Split the slide into 2 columns.

    • Column 1 (Requirements): [Icon: Checklist] with clear bullet points.

    • Column 2 (Handover): [Icon: Folder/Package] - Demonstrates professionalism and systematic process.

  • Instructor Script:

    • “(For Leader/Admin role) This slide is for our operations team. TO team, please ensure all trainees have received the environment setup email.”

    • “(For Trainees) I am assuming you have all met these requirements. We will not stop to ‘teach’ what an API is or ‘install’ Python. We are focusing on architecture.”

    • “[TRAINER’S NOTE:] This slide demonstrates your ‘System Thinking’. It shows you not only prepare content, but also the ‘process’ for others (TO, other Trainers), helping to scale the team’s capability.”

Slide 5: Part 1 - Architectural Context

  • Content:

    • PART 1

    • ARCHITECTURAL CONTEXT

    • Monolith vs. Microservice

  • Visualization:

    • Simple title slide, large, clear font.

    • An image of a fork in the road, one path labeled “Monolith” (straight, wide road), the other “Microservice” (a road splitting into many small paths).

  • Instructor Script:

    • “Let’s begin Part 1. Before we can learn about Microservices, we must deeply understand its ‘enemy’, or more accurately, its ‘predecessor’: The Monolithic Architecture.”

Slide 6: What is a Monolith?

  • Content:

    • MONOLITHIC ARCHITECTURE

    • Concept: The entire application (UI, Logic, Data Access) is built, packaged, and deployed as a single unit.

    • Example (Python): A standard Django project with multiple “apps” (Users, Products, Orders) but all:

      • Share one codebase.

      • Run in one server process (gunicorn).

      • Connect to one database.

    • Analogy: A large Supermarket. Everything is in one building.

  • Visualization: *

    • A simple diagram: [Browser] -> [Web Server (1 large block: UI, Logic, Data)] -> [1 Database]

  • Instructor Script:

    • “This is the most ‘natural’ architecture. When you run django-admin startproject, you are creating a Monolith. Everything is in one place. Like a supermarket, whether you want vegetables, meat, or diapers, it’s all in that one building.”

    • “It’s simple to develop at first, easy to debug because you’re just jumping between functions (in-process calls). But the problems begin when this ‘supermarket’ gets too big.”

Slide 7: Monolith - Pros and Cons

  • Content:

    • THE “BIG BALL OF MUD”

    • Pros:

      • [Icon: Check] Fast initial development.

      • [Icon: Check] Easy to Debug & Test (End-to-End).

      • [Icon: Check] Simple deployment (Deploy 1 unit).

    • Cons - The Pain:

      • [Icon: X] Difficult to Scale: Only 1 module (Payment) is busy, but you must scale the entire app.

      • [Icon: X] Technology Lock-in: “Locked” into 1 stack (e.g., Django 2).

      • [Icon: X] Slow CI/CD: A small change requires a full rebuild/redeploy. High risk.

      • [Icon: X] “Ball of Mud”: The codebase grows, modules become tightly coupled.

  • Visualization:

    • Split into 2 columns, Pros/Cons. The “Cons” column should take 2/3 of the slide and be colored red to emphasize the “pain.”

    • An image of an actual “big ball of mud” for illustration.

  • Instructor Script:

    • “Its advantages are clear: fast and simple at the start. But as the company grows, your ‘supermarket’ gets bigger and bigger, and it turns into a ‘big ball of mud’.”

    • “Imagine it’s Black Friday. Only the ‘Payment’ gateway is congested. With a Monolith, you can’t just add 50 more payment counters. You have to clone the entire supermarket! Build 3 more identical supermarkets just to handle the payment bottleneck. It’s an incredible waste of resources.”

    • “That is the core reason Microservices were born.”

Slide 8: What is a Microservice?

  • Content:

    • MICROSERVICE ARCHITECTURE

    • Concept: An architectural style that structures an application as a collection of small, autonomous services.

    • Characteristics:

      • Services are organized around business capabilities.

      • Independently developed, deployed, and scaled.

      • Communicate via APIs (REST, gRPC) or Message Queues.

    • Analogy: A Shopping Mall.

  • Visualization: *

[Image of Microservice architecture diagram]

* Diagram: `[Browser] -> [API Gateway] -> [Service A], [Service B], [Service C]...`
* Each Service (A, B, C) is its own block, perhaps drawn in a different color.

  • Instructor Script:

    • “And here is the solution: Microservices. Instead of building one supermarket, we build a Shopping Mall.”

    • “Each ‘store’ (The Nike Store, The Apple Store, The Food Court) is a ‘service’. Each store manages its own staff, its own inventory (private database), and can renovate (deploy) itself without shutting down the entire mall.”

    • “They communicate through the ‘common hallways’ or the ‘mall management’ (which is the API Gateway or Message Queue).”

Slide 9: Microservice - Pros and Cons

  • Content:

    • THE TRADE-OFFS

    • Pros:

      • [Icon: Check] Flexible Scaling: Scale only the service (store) you need.

      • [Icon: Check] Independent Deployment: Team A deploys without affecting Team B.

      • [Icon: Check] Polyglot Technology: Service A (Python), Service B (Go).

      • [Icon: Check] Team Autonomy (Ownership): Small, autonomous teams. “You build it, you run it.”

    • Cons - The NEW Pain:

      • [Icon: X] Operational Complexity (DevOps): Needs API Gateway, Service Discovery, Centralized Logging


      • [Icon: X] Network Latency: API calls are always slower than in-process calls.

      • [Icon: X] Data Consistency: The biggest challenge (to be covered in Module 2).

  • Visualization:

    • Split into 2 columns, Pros/Cons. This time, the “Cons” column is also emphasized (in orange).

    • An image of a complex, tangled network grid to illustrate the complexity.

  • Instructor Script:

    • “Sounds like a ‘silver bullet’, right? This is where we need ‘Critical Thinking’. Microservices solve 4 big problems of the Monolith.”

    • “BUT, they create 3 new problems. And these 3 problems are even harder.”

    • “You’ve traded one complex ‘block’ for one complex ‘network’. Now you need an extremely strong DevOps team. You have to handle network calls that can fail at any time. And the biggest headache: how to keep data consistent when ‘Orders’ are in DB 1, but ‘Payments’ are in DB 2?”

    • “These are the trade-offs. There is no free lunch.”

Slide 10: Monolith vs. Microservice (Comparison)

  • Content:

    • HEAD-TO-HEAD COMPARISON

    • (A detailed comparison table)

      Criteria

      Monolith

      Microservice

      Deployment

      Single Unit

      Multiple, Independent Units

      Scaling

      Scale Entire App

      Scale Individual Service

      Technology

      Locked-in (1 stack)

      Polyglot (Diverse)

      Database

      Shared

      Private (Per Service)

      Coupling

      Tightly Coupled

      Loosely Coupled

      Complexity

      Internal (Code)

      Operational (DevOps)

  • Visualization:

    • A clear comparison table filling the slide. The last row (“Complexity”) is highlighted.

  • Instructor Script:

    • “Here is the summary table for both architectures. Look at the last row. Both are ‘complex’, but in different places.”

    • “The Monolith is complex inside the codebase. The Microservice is complex outside, at the operational level.”

    • “[ASK TRAINEES:] So when should we choose which one? (Let them think for 10s). We’ll answer that in Part 5, but for now, let’s move on to ‘If we’ve chosen Microservices, how do we do it right?’”

Slide 11: Part 2 - Design Principles

  • Content:

    • PART 2

    • DESIGN PRINCIPLES

    • How to “split” a Service correctly?

  • Visualization:

    • Title slide.

    • An image of a large rock (Monolith) and a chisel, poised to strike. The question is: “Where to strike?”

  • Instructor Script:

    • “Okay, we’ve decided to ‘break’ the Monolith. But where do we hit it? How do we ‘split’ the service?”

    • “If you split it wrong, you will create something even worse than a Monolith, called a ‘Distributed Monolith’—a mess of services that are still tightly coupled by business logic and data. Part 2 will give us the ‘compass’ to split it correctly.”

Slide 12: Principle #1: Bounded Context (DDD)

  • Content:

    • PRINCIPLE #1: BOUNDED CONTEXT (DDD)

    • Concept: From Domain-Driven Design (DDD).

    • It is a logical boundary within which a specific business term has a consistent, unambiguous meaning.

    • Classic Example: The word “Product”

      • Sales Context: “Product” = Price, Description, Image.

      • Inventory Context: “Product” = Stock (SKU), Location, Weight.

      • Support Context: “Product” = Manuals, Ticket History.

    • Golden Rule: 1 Microservice ≈ 1 Bounded Context.

  • Visualization:

    • Slide split into 3 columns: Sales, Inventory, Support.

    • The word “PRODUCT” is in the middle.

    • Each column lists the different attributes of “Product” within that context.

  • Instructor Script:

    • “The first and most important principle: Bounded Context. This term is a bit academic, but the idea is extremely simple.”

    • “Ask the ‘Sales’ department and the ‘Warehouse’ (Inventory) department ‘What is a Product?’. They will give you two completely different answers.”

    • “Sales cares about ‘Price’, ‘Image’. The Warehouse cares about ‘Weight’, ‘Shelf Location’. These two concepts, despite having the same name ‘Product’, are different things from a business perspective.”

    • “Each of those ‘meaning zones’ is a ‘Bounded Context’. And the golden rule is: A Microservice should be designed to envelop one Bounded Context. Never create one generic ‘Product’ service, because it will violate the Bounded Contexts of both Sales and Inventory.”

Slide 13: Bounded Context (Visualization)

  • Content:

    • DRAWING THE BUSINESS BOUNDARIES

    • Don’t split by technology, split by business.

    • WRONG (Anti-pattern):

      • UserService (CRUD)

      • ProductService (CRUD)

      • OrderService (CRUD)

    • RIGHT (By Bounded Context):

      • Identity & Access (Manages logins, identity)

      • Catalog (Manages products for Sales)

      • Inventory (Manages warehouse stock)

      • Ordering (Manages the ordering process)

      • Payment (Manages payments)

  • Visualization: *

    • A diagram showing a Monolith (E-commerce) being “split” into Bounded Context blocks (as listed in the “RIGHT” column). Arrows show relationships between contexts (e.g., Ordering depends on Catalog and Payment).

  • Instructor Script:

    • “This is the most common mistake. Developers split services by technology or by database table. You create a UserService just to CRUD the User table. This is wrong!”

    • “You must split by business capability. Instead of UserService, think Identity Service (the business of identity). Instead of ProductService, think Catalog Service (the business of sales) and Inventory Service (the business of warehousing).”

    • “This diagram [point to diagram] is a ‘Context Map’. It’s a map of your business domains. This is a mandatory step before you write a single line of microservice code.”

Slide 14: Principle #2: Database per Service

  • Content:

    • PRINCIPLE #2: DATABASE PER SERVICE

    • Concept: Each microservice must own its data and have a private database.

    • Anti-pattern: 2 services (e.g., Order and User) pointing to 1 Shared Database.

    • WHY IS THIS AN “ANTI-PATTERN”?

      • Hidden Coupling: User service changes the Users table schema -> Order service “dies” for no obvious reason.

      • No DB Optimization: Catalog service (read-heavy) wants to use Elasticsearch, but Payment service (transactional) wants PostgreSQL. Impossible!

  • Visualization: *

    • Diagram 1 (WRONG): [Service A], [Service B] -> both pointing to [Shared DB]. A big ‘X’ over it.

    • Diagram 2 (RIGHT): [Service A] -> [DB A], [Service B] -> [DB B]. A big ‘Check’ mark.

  • Instructor Script:

    • “The second golden rule, and the one most violated: One service, one database. I repeat: One service, one database.”

    • “This [point to Diagram 1] is what I call a ‘Distributed Monolith’. You’ve separated the code, but you’re still chained together at the data layer. This is ‘hidden coupling’.”

    • “Imagine the User team decides to rename the username column to email. They deploy. 3 seconds later, your Order service ‘dies’ because its query SELECT username FROM users fails. You can’t deploy independently, so what’s the point of ‘microservices’?”

    • “Not to mention, you lose all optimization. The ‘Catalog’ (Search) team wants to use Elasticsearch for speed, but the ‘Payment’ team needs ACID, they need PostgreSQL. When you share a DB, you will ‘fight’ over who gets priority.”

Slide 15: “But I need the data
”

  • Content:

    • CHALLENGE: HOW TO “JOIN” DATA?

    • Problem: Order service (has user_id) needs the user_name from the User service.

    • Way 1: API Call (Synchronous):

      • Order service calls GET /users/{user_id} on the User service.

      • Con: Tightly coupled. If User service is down, Order service is down.

    • Way 2: Data Replication (Asynchronous):

      • Order service creates its own users table (with just id and name).

      • When the User service changes data (create/update), it “publishes” an Event (e.g., UserUpdated).

      • Order service “listens” for that event and updates its own private users table.

    • Way 3: API Composition (Next Module)

  • Visualization: *

    • Diagram 1 (Sync): [Order] --(API Call)--> [User] --(Response)--> [Order]. Has an hourglass (waiting) icon.

    • Diagram 2 (Async): [User] --(Event)--> [Message Queue] <-- (Listen) -- [Order].

  • Instructor Script:

    • “This is the million-dollar question. ‘Okay, I split the DB. Now my Order service has a user_id. How do I get the user’s name? I can’t JOIN!’”

    • “You have two main ways. Way 1, the lazy way: Direct API call. [Point to Diagram 1] The Order team calls the User team’s API. This is fast, but it ‘couples’ the two services. If the User service is slow or down, the Order service ‘dies’ with it. This is a ‘cascading failure’.”

    • “Way 2, the architect’s way: Asynchronous communication. [Point to Diagram 2] When a new user is created, the User service ‘shouts’ (publishes an event) into a ‘public speaker’ (Message Queue). The Order service (and 10 other services) ‘hears’ it, and updates its own copy of the data it needs (e.g., user_id and user_name) in its own database.”

    • “Way 2 is more complex, but the services are completely ‘decoupled’. User service is down? Order service still runs perfectly because it has its own copy. This is called ‘Eventual Consistency’, which we’ll cover in Module 2.”

Slide 16: Part 3 - Implementation Strategy

  • Content:

    • PART 3

    • IMPLEMENTATION STRATEGY

    • Okay, I have a Monolith, I have the principles. Where do I start?

  • Visualization:

    • Title slide.

    • An image of a construction site, with an old building (Monolith) and a new building being erected right next to it.

  • Instructor Script:

    • “We have our ‘compass’ (DDD, Database per Service). Now it’s time to build. But we can’t just ‘stop’ the live system (that’s making money) for 6 months to do a rewrite.”

    • “Doing that fails 99% of the time. We need a ‘refactor’ strategy that is safe, gradual, and doesn’t disrupt the system.”

Slide 17: Strangler Fig Pattern

  • Content:

    • STRANGLER FIG PATTERN

    • Name: Inspired by the Strangler Fig vine that grows around a host tree. Its roots wrap around, grow upwards, and “strangle” the host. Eventually, the host tree dies, and the fig vine replaces it.

    • Concept: A refactoring strategy that allows you to gradually replace parts of a Monolith with new Microservices.

    • Idea: Place a “Facade” in front of the Monolith. Gradually “cut” traffic and redirect it to new services.

  • Visualization:

    • A real photo of a Strangler Fig vine “strangling” a host tree. Place this next to the architectural diagram.

  • Instructor Script:

    • “And here is the most elegant strategy, named by Martin Fowler: The Strangler Fig Pattern.”

    • “[Point to photo] This image is very literal. The ‘host tree’ is your Monolith. The ‘fig vine’ is your new Microservices. You don’t chop down the host tree (old system) immediately. You ‘plant’ new services beside it, ‘clinging’ to it.”

    • “The new services gradually take all the ‘nutrients’ (i.e., traffic, requests) from the old tree. Until one day, the old tree (Monolith) isn’t doing anything anymore, and you can safely ‘unplug’ it.”

Slide 18: Strangler Fig - How it Works (3 Steps)

  • Content:

    • HOW DOES THE STRANGLER FIG WORK?

    • Step 1: The Facade

      • Install a Reverse Proxy (Nginx, Traefik, API Gateway) in front of the Monolith.

      • All 100% of user traffic now goes through this Proxy.

    • Step 2: The New Service

      • Identify 1 Bounded Context to split (e.g., Notifications).

      • Build the new Notification service (e.g., with FastAPI) with its own DB.

    • Step 3: The Redirect

      • Configure the Proxy: “IF the request is /api/notifications -> route it to the New Service (FastAPI).”

      • “ALL OTHER requests (/api/users, /api/orders
) -> route them to the Old Monolith (Django).”

  • Visualization: *

    • A 3-state diagram:

      1. Day 1: [User] -> [Proxy] -> [Monolith] (100% traffic)

      2. Day 30: [User] -> [Proxy]

        • .../notifications -> [New Service] (10% traffic)

        • .../ (rest) -> [Monolith] (90% traffic)

      3. Day 90: [User] -> [Proxy]

        • .../notifications -> [New Service]

        • .../products -> [New Service 2]

        • .../ (rest) -> [Monolith (now smaller)]

  • Instructor Script:

    • “Here are the 3 implementation steps. Very simple, conceptually.”

    • “Step 1, the most important: Put a Proxy in front as a ‘facade’. If you don’t have one, this is your first task. All users will talk to the Proxy, not directly to the Monolith anymore.”

    • “Step 2: Pick one low-risk business capability (e.g., Sending notifications) and build it as a new service, with its own DB.”

    • “Step 3: The magic is here. You go into the Proxy (Nginx) and add one rule: ‘Anyone calling /api/notifications, don’t go to the old house (Monolith), turn and go to the new house (New Service).’ [Point to Diagram 2]”

    • “And that’s it! You have successfully ‘strangled’ one piece of functionality. The user has no idea anything changed. You repeat this process for /products, /payments
 until the Monolith is ‘dead’.”

Slide 19: Part 4 - Implementation Lab

  • Content:

    • PART 4

    • IMPLEMENTATION LAB

    • Strangling the “Comments” Service from a Blog Monolith

  • Visualization:

    • Title slide.

    • Icons: [Icon: Keyboard], [Icon: Code], [Icon: Terminal].

  • Instructor Script:

    • “Enough theory! Time to code. We are going to implement the Strangler Fig Pattern, for real.”

    • “Our problem: We have a Blog Monolith (built in Django) that manages both Posts and Comments. Our mission: Strangle the Comments functionality into its own separate service (built in FastAPI) without any downtime.”

Slide 20: Lab - Architecture (Before & After)

  • Content:

    • CURRENT STATE (BEFORE)

    • [Browser] -> [Django Gunicorn (Port 8000)]

      • /posts/<id> (Gets post + comments)

      • /api/comments/ (Creates comment)

      • DB: blog_db (shared Post and Comment tables)

    • TARGET STATE (AFTER)

    • [Browser] -> [Nginx Proxy (Port 80)]

      • /posts/<id> (Django) -> Internal Call -> [Comment Service (Port 8001)]

      • /api/comments/ -> Redirect -> [Comment Service (Port 8001)]

    • New Service: FastAPI (Port 8001) + comments_db (Private DB)

  • Visualization:

    • Slide split into “Before” and “After” halves with two clear architectural diagrams.

    • The “After” half must clearly show the role of the Nginx Proxy and the new FastAPI service (in a different color).

  • Instructor Script:

    • “This is our ‘Before’ and ‘After’ diagram.”

    • “[Point to ‘Before’] Currently, Django handles everything on port 8000. Post and Comment share one DB.”

    • “[Point to ‘After’] This is our goal. We will put Nginx at the ‘front door’ (port 80). We will build a new FastAPI service on port 8001, with its own database.”

    • “Then, we configure Nginx: If anyone calls /api/comments/ (to POST a new comment), Nginx will ‘steer’ (redirect) this traffic straight to FastAPI.”

    • “What about the /posts/<id> (read) page? It still goes to Django. BUT, the old Django code (querying comments from DB) will be changed to: make an API call to the FastAPI service (port 8001) to get the comments. This is Part 4a - The Live Demo.”

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

  • Content:

    • PART 4A: LIVE DEMO (TRAINER-LED)

      1. Trainer sets up Nginx as a Proxy for Django.

      1. Trainer builds the Comment Service (FastAPI + private DB).

      1. Trainer configures Nginx location /api/comments/ { ... } to redirect.

      1. Trainer refactors the Django views.py (using requests to call the API).

    • PART 4B: STUDENT LAB (YOUR TURN!)

    • Mission: Strangle the “Reviews” service.

    • Given: An E-commerce Monolith (Django) managing Products and Reviews.

    • Task: Split Reviews into an independent FastAPI service (similar to the Demo).

  • Visualization:

    • Split into 2 columns: “Demo” (Trainer) and “Lab” (Student).

    • “Demo” column has a checklist of steps.

    • “Lab” column has the new problem description.

  • Instructor Script:

    • “I will now demo these 4 steps (Part 4a). Please do not code along. Instead, observe ‘why’ I am doing what I’m doing, especially the Nginx config file and how I change the Django view.”

    • “
 [PERFORM LIVE DEMO] 
”

    • “Okay, you’ve seen how it’s done. Now it’s your turn (Part 4b). You will receive an E-commerce codebase (similar) and your mission is to strangle the Reviews service.”

    • “This is your chance to apply 100% of what we just learned. You have 60 minutes. Myself and the TAs will be here to help.”

Slide 22: Part 5 - Optimization & Critique

  • Content:

    • PART 5

    • OPTIMIZATION & CRITIQUE

    • Best Practices & When NOT to use them

  • Visualization:

    • Title slide.

    • An image of a crossroads, with a green light (Best Practices) and a red light (Anti-Patterns).

  • Instructor Script:

    • “You all did great on the lab. Now for the ‘advanced’ section. This is the ‘hard-won’ experience that takes you from ‘making it work’ to ‘making it right’.”

    • “And more importantly, with ‘Critical Thinking’, we will learn when to say ‘NO’ to microservices.”

Slide 23: Best Practices (The “Do’s”)

  • Content:

    • THE GOLDEN RULES (BEST PRACTICES)

    • 1. “Not” too small:

      • “Nano-services” (e.g., CreateUser service) are an anti-pattern.

      • Start with larger services (by Bounded Context). It’s easier to split than to merge.

    • 2. Prefer Asynchronous:

      • Avoid synchronous API chains (A -> B -> C). If C fails, A & B fail.

      • Use a Message Queue (Events) to “decouple” services.

    • 3. Design for Observability:

      • The 3 Pillars: Logging (ELK), Metrics (Prometheus), Tracing (Jaeger).

      • Without these, you are “blind” when debugging.

    • 4. Conway’s Law:

      • “An application’s architecture will mirror the organization’s communication structure.”

      • Want Microservices? Organize into small, autonomous “squads”.

  • Visualization:

    • A 4-quadrant layout, each with a Best Practice and icon:

      1. [Icon: Magnifying glass (not too small)]

      2. [Icon: Queue]

      3. [Icon: Dashboard]

      4. [Icon: Org chart/Team]

  • Instructor Script:

    • “Here are the 4 rules. One: Don’t split services so small they become ‘nano’. CreateUser and GetUser services should be in the same ‘Identity’ Bounded Context. Remember: ‘Splitting’ one large service into two is EASY. ‘Merging’ 10 nano-services is a nightmare.”

    • “Two: Prefer asynchronous communication (like my ‘public speaker’ example). Avoid synchronous API calls as much as possible.”

    • “Three: [EMPHASIZE] You must have Observability. When 100 services are running, if you don’t have centralized Logging and Tracing, one error will take you 3 days just to find which service caused it.”

    • “Four, Conway’s Law: If your boss still structures teams as ‘Frontend Team’, ‘Backend Team’, ‘DBA Team’, you will 100% create another Monolith. To get Microservices, you must organize into ‘squads’, where each squad owns 1-2 services (end-to-end).”

Slide 24: When NOT to use Microservices

  • Content:

    • CRITIQUE: WHEN TO SAY “NO”?

    • Be an Engineer, not a “Fanboy”.

    • 1. Very Early-stage Startups:

      • When your priority is Time-to-Market.

      • When the business domain is changing “wildly” every week.

      • => A Monolith is much, much faster.

    • 2. Small Team / Weak DevOps:

      • When you have 2 developers and no dedicated DevOps.

      • Microservices will become “Operational Hell.”

    • 3. Unclear Domain:

      • When you don’t even know what your Bounded Contexts are.

      • => You will split it wrong, and the cost to fix it is higher than starting over.

  • Visualization:

    • A strong layout, using a large [Icon: Red light] or [Icon: Stop sign].

    • The slide background could be a light grey or warning red.

  • Instructor Script:

    • “This is my most important slide today, and it demonstrates the ‘Critical Thinking’ of an expert. Do not follow the ‘trend’.”

    • “NEVER use Microservices if you are a 3-person startup and your business logic is unclear. You need speed to market. Use a Monolith. Django/Rails were born for this!”

    • “NEVER use them if your team has no (or weak) DevOps. You will drown in operational overhead.”

    • “And finally, if you can’t even ‘draw’ your Bounded Context Map (like in Part 2), don’t even think about splitting services. You will split it wrong. And it is better to have a good Monolith than a bad, ‘shattered’ microservice architecture.”

Slide 25: Part 6 - Real-world Case Study

  • Content:

    • PART 6

    • REAL-WORLD CASE STUDY

    • Case Study: Uber

  • Visualization:

    • Title slide. The Uber logo.

  • Instructor Script:

    • “Okay, let’s see how a ‘giant’ applied these exact principles. Uber.”

Slide 26: Case Study: Uber

  • Content:

    • CASE STUDY: UBER (FROM A PYTHON MONOLITH)

    • Context (Monolith):

      • Uber (2010) started as a Monolith written in Python (using a custom framework).

      • Everything in one codebase, one DB (PostgreSQL).

    • The Pain:

      • Couldn’t scale when expanding to new cities.

      • Adding new features (UberEATS) to the Monolith was extremely risky.

      • A bug in Payment module -> brought down the entire Finding (ride-hailing) system.

    • The Action (The “Strangler”):

      • They used the Strangler Fig Pattern (exactly as we just learned).

      • “Broke off” Billing first as a new service.

      • The old Monolith, instead of processing payments, was changed to call the API of the new Billing service.

    • The Result:

      • Thousands of microservices (written in Go, Java, Python
).

      • Thousands of independent deployments per day.

      • AI Connection: Allowed them to “plug-in” AI/ML services (like Dynamic Pricing) as independent services without breaking the rest of the app.

  • Visualization:

    • A “Before” and “After” diagram for Uber (simplified).

    • “Before”: 1 block Uber Monolith (Python).

    • “After”: with services like Billing, Trip, Driver, Pricing (AI).

    • Highlight the Pricing (AI) service.

  • Instructor Script:

    • “Uber started just like us, with a Python Monolith.”

    • “When they exploded in growth, they hit the exact 3 ‘pain points’ we discussed. Especially the Payment bug crashing the ride-hailing system.”

    • “And what did they do? They did not do a ‘Big Bang Rewrite’. They used the ‘Strangler Fig Pattern’. They ‘strangled’ the Billing service first. The old Monolith was refactored to call the API of the new Billing service.”

    • “They repeated this hundreds of times, resulting in the architecture of thousands of services they have today.”

    • “And here is the key takeaway for my AI training goals: This architecture allows them to plug in ‘smart’ services. The ‘Dynamic Pricing’ service is an independent AI/ML service. It can be written in Python (for AI libraries), scaled separately (it needs GPUs), and have its models updated continuously, all without affecting the ‘Ride-hailing’ service (written in Go). That is the power of microservices when done right.”

Slide 27: Part 7 - Assessment & Reinforcement

  • Content:

    • PART 7

    • ASSESSMENT & REINFORCEMENT

  • Visualization:

    • Title slide. [Icon: Test/Quiz]

  • Instructor Script:

    • “We’ve reached the end of our journey. Now it’s time to check what we’ve ‘harvested’.”

Slide 28: Assessment (Quiz & Homework)

  • Content:

    • ASSESSMENT

    • 1. Quiz (10 minutes):

      • Please access the iMocha / LMS.

      • Complete the 15-question multiple-choice quiz for Module 1.

      • (Goal: Reinforce theory, Bounded Context, Database per Service).

    • 2. Homework:

      • Complete and submit the source code for Part 4b (Student Lab - Strangling the ‘Reviews’ service).

      • The TO will create a submission link on SharePoint/LMS.

  • Visualization:

    • Split into 2 columns: “Quiz” and “Homework”.

    • “Quiz”: [Icon: Timer]

    • “Homework”: [Icon: Submission/Upload]

  • Instructor Script:

    • “We have two assessments. One, you will take a quick 10-minute quiz right now on iMocha to reinforce the theory.”

    • “Two, your homework is to complete the Lab from Part 4b. This is the ‘proof’ that you can ‘do’ (Objective #4). The TO team will send a submission link. I will be reviewing your code.”

Slide 29: Module 1 Summary & Q&A

  • Content:

    • MODULE 1 SUMMARY

      1. Understand the “pain” of Monoliths and the “trade-offs” of Microservices.

      1. Always split services by Bounded Context (Business).

      1. Always adhere to Database per Service (Technical).

      1. Always use the Strangler Fig Pattern for migration (Strategic).

      1. Always ask: “Do I really need Microservices right now?”

    • Q & A

  • Visualization:

    • 5 key summary bullet points.

    • A large clear space for Q&A.

  • Instructor Script:

    • “Here are the 5 things I want you to ‘take home’ today. If you forget everything else, remember these 5 points. They summarize the mindset of an architect facing this problem.”

    • “Thank you. We now have time for Q&A. Please, your questions.”

Slide 30: Thank You & Next Module

  • Content:

    • THANK YOU!

    • (Your Contact Information)

    • COMING UP (MODULE 2):

    • Module 2: Service Communication Patterns

    • (Sync, Async, API Gateway, Service Discovery, Saga Pattern
)

  • Visualization:

    • Professional layout.

    • A “teaser” for Module 2, showing the connectivity of the learning path.

  • Instructor Script:

    • “Thank you all for your active participation. In Module 1, we ‘split’ the services. In Module 2, we will learn how to ‘make them talk to each other’ effectively and safely, especially how to handle the ‘data consistency’ problem (Saga Pattern) that I promised.”

    • “Have a great and productive day!”