Page 1 of 9

Architecture Style

• Autonomous, Independently Deployable Services
• Various options: Programming language, Database, Communication style, Hosting platform

Problems with Monoliths

• Single Process → releases → reduces simplicity
• Single Host → Easy deployment
• Single DB → Easy deployment
• Consistent Technology

But, as traffic grows, monoliths create problems such as:

• Difficult to deploy (time-consuming)
• Reduces agility
• Difficult to maintain

---

Microservices (Architecting)

• Requires data ownership This limits:
  • Database joins
  • Transactions
  • Eventual consistency

Sometimes, it also requires you to duplicate data.

---

Page 2 of 9

Identifying Microservice Boundaries

1. Start from an existing system

   • Identify loosely coupled components
   • Identify database seams

2. Contains multiple processes

3. Avoid breaking changes

   • Backward compatible

---

Building Microservices

• Focus on good local development
• Use containers / platform as code
• Source control repository per microservice
  • Avoid tight coupling between services
• Setup CI build

---

Standardizing Microservices

1. Logging
2. Health checks
3. Configuration
4. Authentication
5. Build scripts

---

Page 3 of 9

Communicating Between Microservices

Frontend

• API Gateway / Backend for frontend

flowchart LR
    Frontend --> API_Gateway --> Microservices
    Microservices --> Event_Bus

Communication Types

1. Synchronous

   • Usually for a single microservice

2. Asynchronous

   sequenceDiagram
   Client->>Ordering Microservice: POST body
   Ordering Microservice->>Client: 202 Accepted + Task ID
   Ordering Microservice-->>Client: Webhook callback

---

Messaging

flowchart LR
    MS1 --> Event_Bus --> MS2

• Message Types:
  1. Commands
  2. Events

---

Page 4 of 9

Resilient Communication Patterns

1. Expect transient errors
2. Avoiding failures
   • For this, use implementation retries with backoff
   • Example: Polly in .NET

To avoid DDOS:

sequenceDiagram
    Client->>Circuit_Breaker: Call
    Circuit_Breaker->>Service: Passes call through
    Circuit_Breaker->>Client: Blocks calls if errors are detected
    Circuit_Breaker->>Client: Allows calls after timeout if resolved

• Techniques:
  • Passes call through
  • If enough errors are detected, block further calls
  • After a timeout, allows some calls through to see if the problem has been resolved
  • Use caching
  • Message brokers are usually resilient

---

Service Discovery

• Can use Kubernetes for containers
• Zookeeper for internal services
• Platform-provided DNS

---

Page 5 of 9

Securing Microservices

1. Authentication → Access Token

2. Authorization → Already written → Corrected to "Already Written"

3. Secure the Network → Network Security

   graph TD
       SPA --> API_Gateway
       API_Gateway --> S1
       API_Gateway --> S2
       API_Gateway --> S3
       S1 & S2 & S3 --> Virtual_Network

   Use Multiple Layers

4. Defense in Depth

   • Don't rely on a single technique

---

Deploying Microservices

• Automated Deployment is common.

Upgrade Strategies:

1. Stop v1 → Start v2

   graph TD
       v1 --> Stop
       Stop --> v2
       v2 --> Start

2. Blue-Green Deployment

   graph TD
       Blue --> v1
       Green --> v2
       Green --> Switch

3. Rolling Upgrade

   graph TD
       v1 --> Rolling_Upgrade
       Rolling_Upgrade --> v2

---

Page 6 of 9

Monitoring

• Centralized Logs & Telemetry
• Usage Metrics

---

Implementing Microservice Domain Logic

• Requires Domain Logic & Data Access Pattern

  graph TD
      Mobile_App --> BFF --> Catalog --> SQL
      Website --> BFF --> Basket --> Redis
      BFF --> Ordering --> SQL

  Layers:

  • Presentation Layer
  • Service Layer
  • Domain Logic
  • Data Access

---

Page 7 of 9

Domain Logic

Transaction Script:

• A single procedure handles each request from the presentation layer.

• Often calls directly to the DB through a thin wrapper.

  Issues:

  1. Difficult to unit test
  2. Duplication of domain logic
  3. Only suitable for simple microservices

Domain Model:

• Prevents falling into invalid states.

---

Mapping Layer:

a) ORM

• Auto-generate SQL
• Track Modifications

b) Document DBs

• Ready-to-use for key-value pairs, JSON data

Example: Entity Framework

c) Serverless Frameworks

• Data access → No "bindings"

---

• Add all data-related code in this layer.

CQRS (Command Query Responsibility Segregation):

• Avoid using the same model for DB access & data transfer.

---

Page 8 of 9

Kusto DB

• For Log Search & Analytics

Features:

1. Search Diagnostics → Powerful search → Corrected to "Powerful Search"

2. Rich Query & Analytics

3. Business Insights → Integrates with telemetry sources & ML

   Why Kusto is better than other DBs:

Logical Model:

graph TD
    Cluster --> DB --> Table --> Fields(Columns)
    Fields --> Kusto

New Data:

graph TD
    Query --> Kusto --> Management(Dashboard, REST API)

---

• Append-only model

Supports:

• Strings
• Numbers
• DateTime, Timestamp
• GUIDs
• Dynamic
  • JSON-like → Supports nesting

---

Page 9 of 9

Cluster

Cluster is nothing but a group of nodes:

• Gateway
• Admin node
• Data nodes

---

Data Distribution

• Table data is split into shards:

  • Horizontal shard
  • Immutable
  • Independent of other shards

• Shards are distributed across data nodes.

• Database is a physical storage entity (such as Blob storage).

---

Data Ingestion

Done by Data Management Service:

1. Data obtainer
2. Data importer

---

References & Related Topics

• Microservices Architecture by Martin Fowler
• Kubernetes and Container Orchestration
• Resilient Systems Design Patterns