Category Archives: .NET Architecture Weekly

.NET Architecture Weekly #6

Introduction

.NET Architecture Weekly is a journal about learning software architecture on .NET and not just limited* to .NET only.
PS: Why? Because software architecture designs normally can use in any languages or frameworks :).

Week #6

1) Microservices Architecture Design Patterns – Part 4

XII) Asynchronous Messaging Pattern

If we use a pattern such as Chain of Responsibility, the process tends to be blocked after we send a request since we need to wait for response. This issue can be solved using the Asynchronous Messaging Pattern since it makes a request to Event Bus or Queue that does not wait for an immediate response.

---
title: Asynchronous Messaging Pattern
---
graph LR
    UP[User Profile Service] --> |User Update Event| EB[(Event Bus / Queue)]
    EB --> |User Updated Event| B[Basket Service]
    EB --> |User Updated Event| O[Ordering Service]

    style UP fill:#f9d0c4 
    style EB fill:#f0b37e 
    style B fill:#a9dc76 
    style O fill:#a9dc76

XIII) Shared Database Anti-Pattern

Shared Database Pattern in microservices architecture is considered an anti-pattern since microservices get intertangled and both will depend on a single database. But it does have some advantages if you need to have a better transaction control.

---
title: Shared Database Anti-Pattern
---
graph LR
    UI[Browser] -->|HTTP request| GW[API Gateway]
    GW -->|REST call| US[User Service]
    GW -->|REST call| TS[Task Service]
    GW -->|REST call| NS[Notification Service]
    US -->|DB call| DB[(Database)]
    TS -->|DB call| DB
    NS -->|DB call| DB

    style US fill:#f9d0c4 
    style TS fill:#f0b37e 
    style NS fill:#a9dc76

XIV) Decomposition Pattern

Decomposition pattern just like the name, it can use to decompose a monolith application to microservices such as by business capability, subdomain, or bounded context.

---
title: Decomposition Pattern
---
graph LR
    subgraph Monolith Todo App
        UM[User Module]
        TM[Task Module]
        NM[Notification Module]
    end

    subgraph Todo Microservices
        UM --> US[User Service]
        TM --> TS[Task Service]
        NM --> NS[Notification Service]
    end

    style US fill:#f9d0c4 
    style TS fill:#f0b37e 
    style NS fill:#a9dc76

These three patterns for this week mark the end of microservices notes. Next time we will try to explore other things on .NET architectures :).

Reference:
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/asynchronous-message-based-communication

Microservices Decomposition Design Patterns

.NET Architecture Weekly #5

1 Reply

Introduction

Week #5

1) Microservices Architecture Design Patterns – Part 3

XI) Retry Pattern

Retry pattern is a common pattern for recovering from transient errors such as errors that occur for a short period of time. The retry can be implemented in different ways such as Fixed delay, Incremental delay, Exponential Backoff and etc.

---
title: Retry Pattern
---
flowchart LR
    task(Task Service) --x|Request 1| notif(Notification Service)
    task --x |Fixed Delay - Request 2| notif
    task --x |Increment Delay - Request 3| notif
    task --x |Exponential Backoff - Request 4| notif
    notif --> |Response or give up| task

    style task fill:#0f0
    style notif fill:#ff0
    linkStyle 0,1,2,3 stroke:#f00, 2px; 
    linkStyle 4 stroke:#0f0, 2px;

XII) Sidecar Pattern

Sidecar pattern is used to promote separation of concerns by offloading processing of some kind to a separate / side module that gets along with a primary app. Common sidecar modules are logging service, configuration service, monitor service and etc.

---
title: Sidecar Pattern
---
flowchart TD
    main[Primary App] <--> log(Logging Service)
    main <--> config(Configuration Service)
    main <--> monitor(Monitoring Service)
    subgraph Sidecar
        log <--> config
        config <--> monitor
        monitor <--> log
    end

    style main fill:#0f0
    style log fill:#ff0
    style config fill:#f66
    style monitor fill:#0ff

XIII) Strangler / Vine Pattern

Strangler / Vine pattern is a pattern that gradually migrates parts of a monolith to fully microservices architecture.

%%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': {
              'cScale0': '#ff0000', 'cScaleLabel0': '#ffffff',
              'cScale1': '#00ff00',
              'cScale2': '#0000ff', 'cScaleLabel2': '#ffffff'
       } } }%%
timeline
    title Strangling the Todo monolith app
        section Monolith
            Jan : Monolith (API Gateway, User, Task, Notification)
        section Monolith + Microservices
            Feb : Monolith (User, Task, Notification) : Service API Gateway
            Mar : Monolith (Task, Notification) : Service API Gateway : Service User
            Apr : Monolith (Notification): Service API Gateway : Service User : Service Task
        section Microservices
            May : Service API Gateway : Service User : Service Task : Service Notification

XIV) Aggregator Pattern

The Aggregator pattern is a composition pattern in microservices architecture. It looks quite similar with API Gateway pattern initially from diagram, but if you go in detail, the key difference is it will composite response from other services.

---
title: Aggregator Pattern
---
graph LR
  GW[API Gateway] --> Agg[Post Aggregate]
  subgraph Aggregator
    Agg -->|REST call| A[Post Service]What 
    Agg -->|REST call| B[Comment Service]
    Agg -->|REST call| C[Share Service]
    A -->|DB call| D[DB A]
    B -->|DB call| E[DB B]
    C -->|DB call| F[DB C]
  end
   
  style Agg fill:#f9d0c4
  style GW fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76
  style D fill:#78dce8
  style E fill:#78dce8
  style F fill:#78dce8

XV) Chain of Responsibility Pattern

Chain of Responsibility Pattern combines multiple chained outputs and returns it as a single output. A client sends a request to Service A, and from A to Service B and to Service C, then from C, it returns to B and back to A, lastly, it’s from A, it returns response to the client. Therefore, the chains should not be too many, else it will be slowing down the response.

---
title: Chain of Responsibility Pattern
---
graph RL
    UI[Browser] <--> GW[API Gateway]
    GW --> |1. REST call| A[Service A] 
    subgraph Chained 
        A -->|2. REST call| B[Service B] 
        B -->|3. REST call| C[Service C] 
        C -->|4. Response C| B 
        B -->|5. Response B+C| A 
    end 
    A -->|6. Response A+B+C| GW

    style UI fill:#f9d0c4 
    style GW fill:#f0b37e 
    style A fill:#a9dc76 
    style B fill:#a9dc76 
    style C fill:#a9dc76 

    linkStyle default stroke:#000, 1px; 
    linkStyle 1,2,3 stroke:#00f, 2px; 
    linkStyle 4,5,6 stroke:#0f0, 2px;

Reference:
https://blog.bitsrc.io/retry-pattern-3f7221913e41
https://dzone.com/articles/sidecar-design-pattern-in-your-microservices-ecosy-1
https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar

.NET Architecture Weekly #4

Leave a reply

Introduction

Week #4

1) Microservices Architecture Design Patterns – Part 2

VI) API Gateway Pattern

API Gateway Pattern is one of the very common patterns for microservices architecture. In the eShopOnContainers that we learned on .NET Archicteture Weekly #2, it uses the pattern too. The pattern normally has an API Gateway that acts as a single-entry point between client apps and microservices.

---
title: API Gateway Pattern
---
graph LR
  UI[Browser] -->|HTTP request| GW[API Gateway]
  UI --> S3[SPA on Nginx]
  subgraph Backend
    GW -->|REST call| A[User Service]
    GW -->|REST call| B[Task Service]
    GW -->|REST call| C[Notification Service]
    A -->|DB call| D[DB A]
    B -->|DB call| E[DB B]
    C -->|DB call| F[DB C]
  end
  
  style UI fill:#f9d0c4
  style GW fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76
  style D fill:#78dce8
  style E fill:#78dce8
  style F fill:#78dce8

VII) Event Driven Pattern

Event Driven Pattern is a pattern that normally uses an Event Bus that has Publishers/Producers and Subscribers/Consumers. In the eShopOnContainers, RabbitMQ is the message broker.

---
title: Event-Driven Pattern
---
graph LR
  subgraph MS[Message Sender]
    Origin[Microservice Origin]
  end
  subgraph Broker[Message Broker]
    Origin -->|publish| A[Queue A] 
    Origin -->|publish| B[Queue B] 
  end
  subgraph MR[Message Receivers]
    A -->|subscribe| MA[Microservice A]
    B -->|subscribe| MB[Microservice B]
  end
  
  style MS fill:#f0f0f0,stroke:#333,stroke-width:2px
  style Broker fill:#e0e0e0,stroke:#333,stroke-width:2px
  style MR fill:#d0d0d0,stroke:#333,stroke-width:2px
 
  style Origin fill:#ffcccc,stroke:#cc0000,stroke-width:4px
  style A fill:#ccffcc,stroke:#00cc00,stroke-width:4px
  style B fill:#ccccff,stroke:#0000cc,stroke-width:4px
  style MA fill:#ffffcc,stroke:#cccc00,stroke-width:4px
  style MB fill:#ffccff,stroke:#cc00cc,stroke-width:4px

VIII) Backend for Frontend (BFF) Pattern

BFF Pattern is a pattern that is like API Gateway Pattern, some treat them as same since BFF pattern also has at least an API Gateway that acts as a single-entry point between client apps and microservices. But they have a small difference if you see from the diagrams below. From the first diagram, you can normally see BFF just act as API Gateway for their respective UI clients (Mobile Apps, Web SPA Clients…), but for API Gateway, all UI Clients are access via an API Gateway only. It normally serves as a middleware for frontend to process the API result before use by SPA.

---
title: BFF Pattern
---
graph LR
  Web[Web Browser] --> WebBFF[Web BFF]
  Mobile[Mobile App] --> MobileBFF[Mobile BFF]
  WebBFF --> A[User Service]
  WebBFF --> B[Task Service]
  WebBFF --> C[Notification Service]
  MobileBFF --> A[User Service]
  MobileBFF --> B[Task Service]
  MobileBFF --> C[Notification Service]
   
 
  style WebBFF fill:#f9d0c4
  style MobileBFF fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76

---
title: API Gateway Pattern
---
graph LR
  Web[Web Browser] --> GW[API Gateway]
  Mobile[Mobile App] --> GW
  GW --> A[User Service]
  GW --> B[Task Service]
  GW --> C[Notification Service]
   
  style GW fill:#f9d0c4
  style GW fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76

IX) Load Balancer Pattern

The load Balancer Pattern is a common pattern even in monolithic era. It is a service put in front of all the other same services or monolithic instances to split the traffic into different services or instances so if have heavy load of traffic it would not overload a service or instance. For monolith, a load balancer can be a physical load balancer, NGINX or etc. For microservices, an API Gateways sometime is come with load balancing function as well such as YARP.

---
title: Load Balancer Pattern
---
graph LR
  C[Client]
  C --> LB([Load Balancer])
  LB -->|Rest Call| SB1
  LB -->|Rest call| SB2
 
  subgraph Service A 
    SB1(Instance1)
    SB2(Instance2)
  end
   
  style C fill:#f9d0c4
  style LB fill:#f0b37e
  style SB1 fill:#a9dc76
  style SB2 fill:#a9dc76

X) Event Sourcing Pattern

Event Sourcing pattern is a microservice pattern that stores the complete history of an application’s state as a sequence of events instead of just the final value only. It is something like an audit trail and that can be replayed back. Event sourcing normally works with CQRS pattern since it will involve writing and reading from two different databases.
PS: Please do not mix it with the Event Driven pattern, they are two different patterns.

---
title: Event Sourcing Pattern
---
graph TD
  C[Client]
  C --> E1
  E4 --> ES[Event Store]
  ES -->|Publish Event| EB[Event Bus]
  EB -->|Materialized View| DB[Read Database]
  DB -->|Final Value Read By| C1[Client]
  ES -->|Replay Events| RP[Replay]
  
 
  subgraph Event List 
    E1(1. User created) --> E2(2. Email updated) --> E3(3. Address updated) --> E4(4. Phone updated)
  end
   
  style C fill:#f9d0c4
  style C1 fill:#f9d0c4
  style ES fill:#a9dc76
  style DB fill:#a9dc76

Reference:
View at Medium.com

.NET Architecture Weekly #3

Leave a reply

Introduction

Week #3

1) Microservices Architecture Design Patterns – Part 1

What are Microservices Architecture Design Patterns?

Microservices Architecture Design Patterns are some of the common patterns that are used to solve common problems that arise when designing and developing microservices. Some of them can be found in those big tech companies that use a lot of microservices such as Netflix architecture. They help to address challenges such as service discovery, communication, scalability, reliability, security, and data consistency.

I) Service Registry Pattern

Service Registry / Discovery Pattern is a microservice architecture pattern that helps to manage service discovery. It is used to keep track of the location of services and their instances in a distributed system, so we do not need hardcode or maintain the instances url of a service ourselves. You can read What is Eureka Service Discovery in Java and .NET? by clicking the link.

---
title: Service Discovery Pattern
---
graph RL
  SA[Service A]
  SR([Service Registry])
  SA -->|1.Register & 2.Query Service B| SR
  SB1 -->|1.Register| SR
  SB2 -->|1.Register| SR
  SR -->|3.Return Instance1| SA
  SA -->|4.Rest call| SB1

  subgraph Service B
    SB1(Instance1)
    SB2(Instance2)
  end

II) Circuit Breaker Pattern

The Circuit Breaker pattern is a design pattern used in microservices architecture to create resilient and responsive services by limiting the impact of some instance’s failures, latencies and hence can prevent cascading failures and help keep the application alive. It acts as a proxy between the service and its clients and can switch between three states after health check: closed (normal), open (unavailable), and half-open (under observation and partially OK).

---
title: Circuit Breaker Pattern
---
flowchart LR
    id1(Service) --> id2(Circuit Breaker)
    id2 -->|Closed| id3(Client)
    id2 -->|Open| id4(Fallback)
    id2 -->|Half-Open| id5(Probe)
    id3 <-->|Health Check OK| id2
    id4 x--x|Health Check Failed| id2
    id5 --x|Health Check Partially Failed| id2

    style id3 fill:#0f0
    style id4 fill:#f00
    style id5 fill:#ff0

III) SAGA Pattern

SAGA pattern is a design pattern used in microservices architecture to manage complex transactions that involve multiple services. It provides a way to handle data consistency in distributed systems and rollback transaction if there is any failure on any step.

---
title: SAGA Pattern
---
sequenceDiagram
    User-->Booking Service: Booking a seat
    break when the booking process fails
        Booking Service-->>User: Cancel booking
    end
    Booking Service-->>Reservation Service: Reserve seat
    break when the reserve process fails
        Reservation Service-->>Booking Service: Reverse seat
        Booking Service-->>User: Cancel booking
    end
    Reservation Service-->>Payment Service: Process payment
    break when the payment process fails
        Payment Service-->>Reservation Service: Reverse payment
        Reservation Service-->>Booking Service: Reverse seat
        Booking Service-->>User: Cancel booking
    end
    Payment Service-->>Notification Service: Send notification
    break when the notification process fails
        Notification Service-->>Payment Service: Cancel confirmation
        Payment Service-->>Reservation Service: Reverse payment
        Reservation Service-->>Booking Service: Reverse seat
        Booking Service-->>User: Cancel booking
    end

IV) Command Query Responsibility Segregation (CQRS) Pattern

CQRS is a microservice architecture pattern that separates read and write operations into two services. It can improve performance, scalability, and security of an application.

---
title: CQRS Pattern
---
graph TD
  Users -->|REST call| Command
  Users -->|REST call| Query
  subgraph Write
    Command -->|DB call|DB1[DB Write]
  end
  subgraph Read
    Query -->|DB call| DB2[DB Read]
  end
  DB1 -->|Eventual Consistency| DB2

  style Users fill:#f0b37e
  style Command fill:#a9dc76
  style Query fill:#a9dc76
  style DB1 fill:#78dce8

V) Bulkhead Pattern

The bulkhead pattern is a microservice architecture pattern that partitions different parts of an application into isolated pools. This helps to contain failures, attacks or performance degradations from spreading to other parts of the system.

---
title: Bulkhead Pattern
---
graph TD
  subgraph Workload and Connection Pool
    Workload1 --x CPA[Connection Pool]
    Workload2 --> CPB[Connection Pool]
    Workload2 --> CPC[Connection Pool]
  end
  CPA --xSVA[Service A]
  CPB -->SVB[Service B]
  CPC -->SVC[Service C]

style Workload1 fill:#ff0000,color:#fff
style CPA fill:#ff0000,color:#fff
style SVA fill:#ff0000,color:#fff

style Workload2 fill:#00ff00
style CPB fill:#00ff00
style CPC fill:#00ff00
style SVB fill:#00ff00
style SVC fill:#00ff00

References:
View at Medium.com
https://levelup.gitconnected.com/12-microservices-pattern-i-wish-i-knew-before-the-system-design-interview-5c35919f16a2
https://www.edureka.co/blog/microservices-design-patterns
https://blog.bitsrc.io/how-to-use-saga-pattern-in-microservices-9eaadde79748
View at Medium.com
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead

.NET Architecture Weekly #2

1 Reply

Introduction

Week #2

1) .NET Microservices Architecture

Today we will try to learn microservices on .NET via eShopOnContainers. eShopOnContainers is a cross-platform .NET sample microservices that runs on Linux and/or Windows containers. Below is the main overall architecture for the eShopOnContainers for docker or local development environment using mermaid.js.

---
title: eShopOnContainers Architecture
---
graph LR
  subgraph CA[Client apps]
    APP[Mobile apps]
    SPA[Web SPA]
    MVC[Web MVC]
  end
  subgraph DH[Docker Host]
    MVC --> COREMVC[ASP.NET Core MVC]
    subgraph GW[API Gateway]
      GW1[Mobile-Shopping]
      GW2[Web-Shopping]
    end
    APP --> GW
    SPA --> GW
    COREMVC --> GW
    APP --> ID[Identity Service]
    SPA --> ID
    COREMVC --> ID
    Admin --> GW
    GW -->|REST call| A[Catalog Service]
    GW -->|REST call| B[Ordering Service]
    GW -->|REST call| C[Basket Service]
    ID --> |DB call| D[SQL Server]
    A -->|DB call| E[SQL Server]
    B -->|DB call| F[SQL Server]
    C -->|DB call| G[Redis]
    D -->|Pub/Sub| EB
    E -->|Pub/Sub| EB
    F -->|Pub/Sub| EB
    G -->|Pub/Sub| EB
    subgraph EBGrp[Event Bus]
      EB[RabbitMQ]
    end
    subgraph Admin[Admin Services]
      A1[Web Status]
      A2[Seq Logging]
      A3[Webhooks API]
    end
  end
  
  style CA fill:#f0f0f0,stroke:#333,stroke-width:2px
  style DH fill:#e0e0e0,stroke:#333,stroke-width:2px
  style GW fill:#d0d0d0,stroke:#333,stroke-width:2px
  style EBGrp fill:#c0c0c0,stroke:#333,stroke-width:2px
  style Admin fill:#b0b0b0,stroke:#333,stroke-width:2px

  style APP fill:#ffcccc,stroke:#cc0000,stroke-width:4px
  style SPA fill:#ccffcc,stroke:#00cc00,stroke-width:4px
  style MVC fill:#ccccff,stroke:#0000cc,stroke-width:4px
  style COREMVC fill:#ffffcc,stroke:#cccc00,stroke-width:4px
  style ID fill:#ffccff,stroke:#cc00cc,stroke-width:4px
  style A fill:#ccffff,stroke:#00cccc,stroke-width:4px
  style B fill:#ff99cc,stroke:#cc3399,stroke-width:4px
  style C fill:#99ffcc,stroke:#33cc99,stroke-width:4px
  style D fill:#99ccff,stroke:#3399cc,stroke-width:4px
  style E fill:#ffff99,stroke:#cccc33,stroke-width:4px
  style F fill:#ff99ff,stroke:#cc33cc,stroke-width:4px
  style G fill:#99ffff,stroke:#33cccc,stroke-width:4px
  style EB fill:#9999ff,stroke:#3333cc,stroke-width:4px
  style A1 fill:#ff9999,stroke:#cc3333,stroke-width:4px
  style A2 fill:#99ff99,stroke:#33cc33,stroke-width:4px
  style A3 fill:#9999ff,stroke:#3333cc,stroke-width:4px

As you might feel, the architecture is similar to the API Gateway pattern that we used for the Todo app.

---
title: API Gateway Pattern
---
graph LR
  UI[Browser] -->|HTTP request| GW[API Gateway]
  UI --> S3[SPA on Nginx]
  subgraph Backend
    GW -->|REST call| A[User Service]
    GW -->|REST call| B[Task Service]
    GW -->|REST call| C[Notification Service]
    A -->|DB call| D[DB A]
    B -->|DB call| E[DB B]
    C -->|DB call| F[DB C]
  end
 
  style UI fill:#f9d0c4
  style GW fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76
  style D fill:#78dce8
  style E fill:#78dce8
  style F fill:#78dce8

One thing worth noting is for this .NET microservices, the Identity Service does not go through API Gateway but can be accessed directly from the browser.

Another pattern that can be found on the eShopOnContainer architecture is the Event-Driven pattern. It is an Event Bus that has Publishers/Producers and Subscribers/Consumers. The message broker for eShopOnContainers is RabbitMQ.

---
title: Event-Driven Pattern
---
graph LR
  subgraph MS[Message Sender]
    Origin[Microservice Origin]
  end
  subgraph Broker[Message Broker]
    Origin -->|publish| A[Queue A] 
    Origin -->|publish| B[Queue B] 
  end
  subgraph MR[Message Receivers]
    A -->|subscribe| MA[Microservice A]
    B -->|subscribe| MB[Microservice B]
  end
 
  style MS fill:#f0f0f0,stroke:#333,stroke-width:2px
  style Broker fill:#e0e0e0,stroke:#333,stroke-width:2px
  style MR fill:#d0d0d0,stroke:#333,stroke-width:2px

  style Origin fill:#ffcccc,stroke:#cc0000,stroke-width:4px
  style A fill:#ccffcc,stroke:#00cc00,stroke-width:4px
  style B fill:#ccccff,stroke:#0000cc,stroke-width:4px
  style MA fill:#ffffcc,stroke:#cccc00,stroke-width:4px
  style MB fill:#ffccff,stroke:#cc00cc,stroke-width:4px

That all for today .NET Microservices Architecture with eShopOnContainers, hope in future will learn other things from the sample. If you wish to know more than, remember it has an ebook, you can download via the link below:
.NET Microservices: Architecture for Containerized .NET Applications

2) The Full-stack Software Design & Architecture map
This post is suitable for developers who want to transform to become a solution architect. It discussed from low-level to high-level of software design and architecture. The author has split it into nine stages that we can follow as below:
1. Learn how to write clean code
2. Understand the differences between each mainstream paradigm and who OOP is the most beneficial for architecture
3. Re-learn OOP programming but this time with model-driven design in mind
4. Learn the OOP design principles for keeping code flexible and testable
5. Learn the patterns that are solutions to commonly solved problems and how to apply them at the class-level
6. Learn how to manage relationships between components, express high-level policy, and identify architectural boundaries
7. Learn the different approaches to organizing our code into high-level modules and defining the relationships between them
8. Learn the architectural patterns that implement one or more architectural styles to solve a problem
9. Learn the enterprise patterns that be suit your choose architectural pattern.

.NET Architecture Weekly #1

Leave a reply

Introduction

Week #1

1. Microservices Architecture

In today’s cloud or cloud native world, what are some of the popular software architectures? Microservices, serverless, event-driven are some of them. Today we will focus on learning about microservices architecture.

What are Microservices?

Microservices are small, independent, and loosely coupled services that communicate with each other through well-defined APIs. They allow developers to focus on specific business functions, scale them independently, deploy them faster, and update them more frequently. For e.g., a Todo app can be separated into User Service, Task Service, and Notification Service APIs instead of just one service that provides User, Task and Notification APIs like what normally inside monolith app. Below is an example of a simple Todo app architecture diagram using mermaid.js.

graph LR
  UI[Browser] -->|HTTP request| GW[API Gateway]
  GW -->|REST call| A[User Service]
  GW -->|REST call| B[Task Service]
  GW -->|REST call| C[Notification Service]
  A -->|DB call| D[DB A]
  B -->|DB call| E[DB B]
  C -->|DB call| F[DB C]
  

  style UI fill:#f9d0c4
  style GW fill:#f0b37e
  style A fill:#a9dc76
  style B fill:#a9dc76
  style C fill:#a9dc76
  style D fill:#78dce8
  style E fill:#78dce8
  style F fill:#78dce8

From the diagram above, we can see a browser connects to API Gateway using HTTP request. The browser can load a frontend UI such as React, Angular, or etc., then the API Gateway is the one exposed to internet, all the other microservices will be available to the API Gateway only without accessible directly from the internet. Lastly, each microservice has its own DB. Database per service is one of the principles of microservices though some might choose to have same DB for all of the services depending on the application architecture requirements, but shared database is not a recommended practice for microservices architecture since microservices is loosely coupled.

Who uses microservices architecture?

One of the leading examples of who uses microservice architecture is Netflix. According to CloudZero.com, Netflix initially used monolithic architecture but switched to microservices architecture after a major outage.

For context, Netflix experienced a major outage in August 2008. That was back when it used monolithic architecture and private data centers.

You can read the about some of the Netflix architecture on the links below:
Adopting Microservices at Netflix: Lessons for Architectural Design
Adopting Microservices at Netflix: Lessons for Team and Process Design
Understanding design of microservices architecture at Netflix
Netflix decoded: Backend architecture & client structural component explained
Netflix System Design- Backend Architecture

2. Solution Architect: Processes, Role Description, Responsibilities, and Certifications

AltexSoft wrote a blog post on Solution Architect: Processes, Role Description, Responsibilities, and Certifications. It discussed about what is a solution architect, Enterprise architect vs solution architect vs technical architect, solution architecture and it main processes, role description and responsibilities, skillset recommendation, background, and certification, and lastly when a company needs a solution architecture consulting.

3. What is a Solution Architect?

What is a Solution Architect? What are the job scopes, soft skills and job-related skills needed for a solution architect? What is a Solution Architect? post provides a mind-map of possible answers.