Microservices - realestateexplorer/SystemDesign GitHub Wiki

What is OAuth 2.0?

create a diagram of microservices application

Of course! Here is a diagram and a detailed explanation of a typical microservices application, using a common e-commerce platform as a concrete example.

We'll look at it in a few ways:

  1. A high-level visual description.
  2. An ASCII art diagram for easy viewing anywhere.
  3. A Mermaid code block that can be rendered into a clean diagram by many tools (like GitHub, GitLab, or online editors).
  4. A detailed breakdown of each component and the interaction flows.

1. High-Level Visual Concept

Imagine a system where the user interacts with a single entry point (the API Gateway). Behind this gateway, instead of one giant application, there are many small, independent services. Each service is responsible for one specific business function (like managing products, handling orders, or processing payments). They have their own databases and communicate with each other over the network, often through a combination of direct calls and a message bus for events. Surrounding these services are other essential infrastructure components for discovery, configuration, and monitoring.

2. ASCII Art Diagram

This diagram shows the main components and their relationships.

+--------------------------------------------------------------------------------------------------+
|                                        USER'S DEVICE                                             |
| +-------------------------+      +-------------------------+                                     |
| |      Web Browser        |      |      Mobile App         |                                     |
| +-------------------------+      +-------------------------+                                     |
|             |                            |                                                       |
+-------------|----------------------------|-------------------------------------------------------+
              |                            |
              +-----------+----------------+
                          |
                          v
+--------------------------------------------------------------------------------------------------+
|                                    EDGE / API LAYER                                              |
|                       +-----------------------------------+                                      |
|                       |            API Gateway            | (Authentication, Routing, Rate Limiting) |
|                       +-----------------------------------+                                      |
|                                         |                                                        |
+-----------------------+-----------------|----------------------+---------------------------------+
                        |                 |                      |
                        v (REST/gRPC)     v (REST/gRPC)          v (REST/gRPC)
+--------------------------------------------------------------------------------------------------+
|                                   APPLICATION SERVICES                                           |
|                                                                                                  |
|  +-----------------+    +------------------+    +-----------------+     +----------------------+  |
|  |  User Service   |    |  Product Service |    |  Order Service  |     |   Payment Service    |  |
|  +-----------------+    +------------------+    +-----------------+     +----------------------+  |
|  | Owns User DB    |    | Owns Product DB  |    | Owns Order DB   |     | (Talks to Stripe/etc)|  |
|  +-----------------+    +------------------+    +-----------------+     +----------------------+  |
|         ^                                              |                         ^               |
|         | (REST)                                       | (Publishes Event)       | (Consumes Event)|
|         |                                              v                         |               |
|         +-------------------------------------<  Message Bus (Kafka/RabbitMQ)  >-----------------+
|                                                        |                         ^               |
|                                                        | (Consumes Event)        | (Consumes Event)|
|                                                        v                         |               |
|  +-----------------+                          +--------------------+    +----------------------+  |
|  |  Cart Service   |                          |  Shipping Service  |    | Notification Service |  |
|  +-----------------+                          +--------------------+    +----------------------+  |
|  | Owns Cart DB    |                          | Owns Shipping DB   |    | (Sends Emails/SMS)   |  |
|  |   (e.g. Redis)  |                          +--------------------+    +----------------------+  |
|  +-----------------+                                                                             |
+--------------------------------------------------------------------------------------------------+
|                                  SUPPORTING INFRASTRUCTURE                                       |
|                                                                                                  |
|  +---------------------+   +-----------------+   +------------------+   +-----------------------+  |
|  | Service Discovery   |   |  Config Server  |   | Logging/Metrics  |   | Distributed Tracing   |  |
|  |    (e.g. Eureka)    |   |  (e.g. Spring   |   | (Prometheus, ELK)|   |    (e.g. Jaeger)      |  |
|  |                     |   |   Cloud Config) |   |                  |   |                       |  |
|  +---------------------+   +-----------------+   +------------------+   +-----------------------+  |
|         ^       ^                  ^                     ^                      ^                |
|         |       |                  |                     |                      |                |
|         +-------+---- All Microservices Register & Communicate with These ------+                |
+--------------------------------------------------------------------------------------------------+

3. Mermaid Diagram

You can copy and paste the code below into a Mermaid-compatible editor (like Mermaid Live Editor) to generate a clean, graphical diagram.

graph TD
    subgraph "User Layer"
        WebClient[<i class="fa fa-desktop"></i> Web Browser]
        MobileClient[<i class="fa fa-mobile"></i> Mobile App]
    end

    subgraph "Edge Layer"
        APIGateway[<i class="fa fa-server"></i> API Gateway]
    end

    subgraph "Core Microservices"
        UserService[<i class="fa fa-user"></i> User Service]
        ProductService[<i class="fa fa-box"></i> Product Service]
        CartService[<i class="fa fa-shopping-cart"></i> Cart Service]
        OrderService[<i class="fa fa-receipt"></i> Order Service]
        PaymentService[<i class="fa fa-credit-card"></i> Payment Service]
        ShippingService[<i class="fa fa-truck"></i> Shipping Service]
        NotificationService[<i class="fa fa-envelope"></i> Notification Service]
    end
    
    subgraph "Data Stores"
        UserDB[(<i class="fa fa-database"></i> User DB)]
        ProductDB[(<i class="fa fa-database"></i> Product DB)]
        CartDB[(<i class="fa fa-database"></i> Cart DB)]
        OrderDB[(<i class="fa fa-database"></i> Order DB)]
        ShippingDB[(<i class="fa fa-database"></i> Shipping DB)]
    end

    subgraph "Asynchronous Communication"
        MessageBus{<i class="fa fa-exchange-alt"></i> Message Bus <br>(e.g., Kafka, RabbitMQ)}
    end

    subgraph "Infrastructure Services"
        ServiceDiscovery[<i class="fa fa-compass"></i> Service Discovery]
        ConfigServer[<i class="fa fa-cogs"></i> Config Server]
        Observability[<i class="fa fa-chart-line"></i> Logging, Metrics, Tracing]
    end

    %% Client to Gateway
    WebClient --> APIGateway
    MobileClient --> APIGateway

    %% Gateway to Services (Synchronous REST/gRPC Calls)
    APIGateway -->|/users| UserService
    APIGateway -->|/products| ProductService
    APIGateway -->|/cart| CartService
    APIGateway -->|/orders| OrderService

    %% Service to Database (Database per Service Pattern)
    UserService --- UserDB
    ProductService --- ProductDB
    CartService --- CartDB
    OrderService --- OrderDB
    ShippingService --- ShippingDB
    
    %% Service to Service (Synchronous REST/gRPC Call)
    OrderService -->|Requests Payment| PaymentService
    
    %% Event-Driven Asynchronous Communication
    OrderService -- Publishes "OrderPlaced" --> MessageBus
    MessageBus -- Consumes "OrderPlaced" --> PaymentService
    MessageBus -- Consumes "OrderPlaced" --> ShippingService
    MessageBus -- Consumes "OrderPlaced" --> NotificationService
    
    %% Infrastructure Connections
    UserService <--> ServiceDiscovery
    ProductService <--> ServiceDiscovery
    OrderService <--> ServiceDiscovery
    
    UserService --> ConfigServer
    ProductService --> ConfigServer
    OrderService --> ConfigServer
    
    UserService --> Observability
    ProductService --> Observability
    OrderService --> Observability

    %% Style
    classDef service fill:#d4edff,stroke:#004085,stroke-width:2px;
    class UserService,ProductService,CartService,OrderService,PaymentService,ShippingService,NotificationService service;

4. Component Breakdown and Interaction Flow

A. Core Components

  1. Clients (Web/Mobile App): The user-facing applications. They don't know about the individual microservices; they only talk to the API Gateway.
  2. API Gateway: The single entry point for all client requests.
    • Responsibilities:
      • Routing: Directs incoming requests to the correct microservice. (/api/products goes to Product Service).
      • Authentication & Authorization: Verifies user identity before forwarding requests.
      • Rate Limiting: Protects services from being overloaded.
      • Request Aggregation: Can combine results from multiple services into a single response.
  3. Microservices: Each is a self-contained application focused on a single business capability.
    • User Service: Handles user registration, login, profiles.
    • Product Service: Manages the product catalog, inventory, and pricing.
    • Cart Service: Manages the user's shopping cart. Often uses a fast in-memory database like Redis.
    • Order Service: Handles order creation, history, and status. It often acts as a coordinator (orchestrator).
    • Payment Service: Integrates with external payment gateways (like Stripe, PayPal) to process payments.
    • Shipping Service: Manages logistics, calculating shipping costs, and tracking shipments.
    • Notification Service: Sends emails, SMS, or push notifications to users (e.g., "Order Confirmed").
  4. Database Per Service: This is a critical pattern. Each microservice manages its own private database. This ensures loose coupling—a change to the Product database schema doesn't affect the User service.
  5. Communication Patterns:
    • Synchronous (REST/gRPC): Used for request/response interactions. For example, the API Gateway makes a synchronous call to the Product Service to fetch product details and waits for the response.
    • Asynchronous (Message Bus): Used for event-driven communication. This decouples services and improves resilience. When an order is created, the Order Service doesn't directly call the Payment and Shipping services. Instead, it publishes an OrderCreated event to the message bus. Other services can then react to this event independently.

B. Supporting Infrastructure

  1. Service Discovery: How do services find each other in a dynamic environment where instances are constantly being created and destroyed? They register themselves with a Service Discovery server (like Eureka or Consul), which acts as a "phone book".
  2. Config Server: Provides centralized configuration management for all services. This avoids having configuration files scattered across every service and allows for dynamic updates without redeploying.
  3. Observability (Logging, Metrics, Tracing):
    • Centralized Logging: Logs from all services are aggregated into a central system (like ELK Stack) for easy searching and analysis.
    • Metrics: Each service exposes metrics (e.g., response time, error rate). A tool like Prometheus scrapes these metrics, and Grafana visualizes them in dashboards.
    • Distributed Tracing: In a microservices architecture, a single user request can travel through many services. Tracing tools (like Jaeger or Zipkin) assign a unique ID to each request, allowing you to trace its entire journey across the system, which is invaluable for debugging.

C. Example Interaction Flow: Placing an Order

  1. The user clicks "Checkout" in the Web Browser.
  2. The browser sends a POST /api/orders request to the API Gateway.
  3. The API Gateway authenticates the user's token and routes the request to the Order Service.
  4. The Order Service receives the request, validates the cart details (perhaps by calling the Cart Service), and creates an order record in its own Order DB, marking it as PENDING.
  5. The Order Service then publishes an OrderCreated event to the Message Bus.
  6. It immediately returns a 201 Created response to the API Gateway, which then goes back to the user's browser. The user sees an "Order placed, processing payment..." message. The user experience is fast because they aren't waiting for the entire backend process to complete.
  7. Asynchronously, several services react to the OrderCreated event:
    • The Payment Service consumes the event, calls the external payment provider to charge the user's card. On success, it might publish a PaymentSuccessful event.
    • The Shipping Service consumes the event and starts preparing the shipment.
    • The Notification Service consumes the event and sends an "Order Confirmation" email to the user.
  8. The Order Service might also listen for the PaymentSuccessful event to update the order status from PENDING to CONFIRMED.

explain oauth 2.0

Of course. Let's break down OAuth 2.0 from a simple analogy to the technical details.

The Simple Analogy: The Hotel Key Card

Imagine you're staying at a hotel.

  • You are the Resource Owner. You own the rights to your hotel room.
  • Your Hotel Room is the Resource. It's the data or functionality you want to protect (like your photos, contacts, or profile information).
  • The Hotel Front Desk is the Authorization Server. It's the only entity trusted to issue keys.
  • A Cleaning Service you hired is the Client Application. It's a third-party app that wants to do something on your behalf (clean your room).

Now, the cleaning service needs to get into your room. What do you do?

The Old, Bad Way (Username/Password): You give the cleaning service a copy of your personal master key.

  • Problem: The cleaner now has access to everything—your room, the minibar, your safe. They can come back anytime they want, and if they lose the key, someone else can use it. The only way to stop them is to change the locks on the entire hotel for yourself, which is a huge pain.

The OAuth 2.0 Way (Delegated Authorization):

  1. You go to the hotel front desk (Authorization Server) with the cleaner.
  2. You tell the front desk, "Please give this cleaning service (Client Application) a key card that only works for my room (Resource), only for the next hour, and only for cleaning (it can't be used to charge things to your room)." This is defining the scope.
  3. The front desk authenticates you (checks your ID) and gives the cleaner a special, limited-use key card. This key card is the Access Token.
  4. The cleaner now goes to your hotel room door (Resource Server) and swipes the key card. The door's electronic lock checks if the key is valid and, if so, lets them in.

This is the essence of OAuth 2.0. You never give your password to the application. You delegate specific, limited permissions to it through a trusted third party.

The Technical Explanation

OAuth 2.0 is an authorization framework. It is not for authentication (proving who you are), but for authorization (defining what an application is allowed to do on your behalf).

The Four Key Roles

  1. Resource Owner: The end-user who owns the data (e.g., you, the owner of your Google Photos).
  2. Client Application: The third-party application that wants to access the user's data (e.g., a photo printing service).
  3. Authorization Server: The server that presents the login and consent screen to the user and issues access tokens after they approve (e.g., accounts.google.com).
  4. Resource Server: The API server that hosts the user's data and is protected by OAuth (e.g., photos.googleapis.com).

The Most Common Flow: "Authorization Code Grant"

This is the most common and secure flow for web applications. Let's walk through the steps when you click "Log in with Google" on a website called PhotoPrint.com.

  1. User Initiates: You click "Print my Google Photos" on PhotoPrint.com.

  2. Redirect to Authorization Server: PhotoPrint.com redirects your browser to Google's Authorization Server with a query string containing:

    • client_id: Identifies PhotoPrint.com.
    • redirect_uri: The URL Google should send you back to after you're done.
    • scope: What PhotoPrint.com wants to do (e.g., read_photos, user_profile).
    • response_type=code: Specifies that we want an "Authorization Code."

  3. User Authenticates and Consents:

    • Google asks you to log in (if you aren't already). This is authentication.
    • Google then shows you a consent screen: "PhotoPrint.com would like to: View your photos, View your basic profile information." This is authorization.
    • You click "Allow."

  4. Authorization Code is Granted:

    • Google's Authorization Server redirects your browser back to the redirect_uri provided by PhotoPrint.com.
    • In the URL is a temporary, one-time-use authorization_code.
    • https://photoprint.com/callback?code=A_LONG_SECRET_CODE

  5. Client Exchanges Code for a Token (The Secure Part):

    • Your browser has the code, but PhotoPrint.com's backend server now takes over.
    • The server makes a secure, direct, server-to-server request to Google's Authorization Server. This request includes:
      • The authorization_code it just received.
      • Its client_id.
      • Its client_secret (a password that proves it really is PhotoPrint.com).
    • This step happens on the back-channel, hidden from the user's browser, which is why it's secure.

  6. Access Token is Issued:

    • Google verifies all the information and, if correct, sends back an access_token (and often a refresh_token).

  7. Client Accesses the Resource:

    • PhotoPrint.com can now use this access_token to make requests to Google's Resource Server (the Google Photos API).
    • It includes the token in the HTTP request header: Authorization: Bearer <THE_ACCESS_TOKEN>
    • The Google Photos API validates the token and, if the scope is correct (read_photos), it returns your photos to PhotoPrint.com.

The Key Components (The "Tokens")

  • Access Token: A short-lived string that acts as the temporary key card. It is sent with every request to the Resource Server to prove the client has permission to access the data. It's a "Bearer" token, meaning whoever possesses it ("bears" it) can use it.
  • Refresh Token: A long-lived token used to get a new access_token when the old one expires. This way, the user doesn't have to log in and grant permission every hour. The refresh token is stored securely by the client application.

Other OAuth 2.0 Flows (Grant Types)

The "Authorization Code" flow is for traditional web apps with a backend. Other flows exist for different scenarios:

  • Authorization Code with PKCE: The new standard for mobile apps and single-page web apps (SPAs). It adds an extra security step to prevent the authorization code from being intercepted.
  • Client Credentials Grant: For machine-to-machine communication where there is no user (e.g., a backend service calling another internal API). The application is accessing its own resources, not a user's.
  • Implicit Grant (Legacy): An older, less secure flow for SPAs where the access token was sent directly to the browser. It's now deprecated in favor of the PKCE flow.

Summary: Why is OAuth 2.0 so important?

  • Security: Users never share their passwords with a third-party application.
  • Limited Scope: Applications can only request the permissions they need. You can grant access to your photos without giving access to your email.
  • Revocable Access: As a user, you can go to your Google Account settings at any time and see a list of all applications you've authorized. You can revoke access for any of them with a single click, without having to change your password.
  • Better User Experience: Users don't need to create a new username and password for every single service they use.