Microservices Architecture: Types, Subtypes, and Design Patterns Matrix

Intro

When we start building a brand-new project, a monolith is almost always the smartest choice. You spin up a single ASP.NET Core project, connect it to a relational database, write clean domain entities, and ship features quickly. In the early days, everything is fast: debugging happens right inside Visual Studio, database queries are straightforward SQL joins, and deploying means publishing a single container or binary.

Fast forward three years.

Your engineering team has grown from 5 engineers to 60. Pull requests sit in queues because everyone is touching the same codebase. A memory leak in an obscure PDF report generation module suddenly takes down the entire customer checkout flow on a busy Friday afternoon. Deployments turn into stressful late-night release windows where a dozen teams hold their breath hoping nothing breaks.

That is usually the moment someone in the room says: “We need to break this down into microservices.”

Microservices solve very real organizational, deployment, and scalability bottlenecks. But let’s be candid: microservices are not a silver bullet. The moment you split your monolith into separate services, you trade the simplicity of in-memory method calls for network latency, ACID transactions for eventual consistency, and straightforward debugging for distributed tracing.

In this guide, I want to walk through microservices from an engineer’s perspective:

1. What microservices actually look like in real production systems
2. The distinct types and subtypes of services you will build
3. A comprehensive master table showing exactly which design pattern solves which distributed systems headache
4. Concrete .NET Core code examples and architecture diagrams
5. An interactive checklist you can use to assess your system’s production readiness

What is Microservices Architecture?

At its core, Microservices Architecture is an approach where a large application is split into a collection of small, loosely coupled, independently deployable services—each modeled around a distinct business domain.

Instead of having one giant application that handles Users, Orders, Payments, Shipping, and Notifications all inside the same process:

• Each service runs in its own isolated process or container.
• Each service owns its own private database (the fundamental Database-per-Service rule).
• Services talk to one another over lightweight network protocols (REST, gRPC, or Asynchronous Message Brokers like Kafka and RabbitMQ).
• Individual teams can build, test, deploy, and scale their service without waiting on or coordinating with other teams.

+-----------------------------------------------------------------------------+
|                               Client Layer                                  |
|               (Mobile Apps, Web SPAs, Partner APIs, IoT)                   |
+-----------------------------------------------------------------------------+
                                       │
                                       ▼
+-----------------------------------------------------------------------------+
|                          API Gateway / BFF Layer                            |
|             (Routing, SSL, AuthN/AuthZ, Rate Limiting, YARP)                |
+-----------------------------------------------------------------------------+
                 │                            │                         │
                 ▼                            ▼                         ▼
   +──────────────────────────+  +─────────────────────────+  +─────────────────────────+
   |      Order Service       |  |     Payment Service     |  |    Inventory Service    |
   |  (ASP.NET Core / gRPC)   |  |  (ASP.NET Core / REST)  |  |  (ASP.NET Core / gRPC)  |
   |   ┌──────────────────┐   |  |   ┌─────────────────┐   |  |   ┌─────────────────┐   |
   |   │ Private SQL DB   │   |  |   │ Private SQL DB  │   |  |   │ Private NoSQL   │   |
   |   └──────────────────┘   |  |   └─────────────────┘   |  |   └─────────────────┘   |
   +──────────────────────────+  +─────────────────────────+  +─────────────────────────+
                 │                            │                         │
                 └──────────────────────┬─────┴─────────────────────────┘
                                        ▼
+-----------------------------------------------------------------------------+
|                      Event Streaming / Message Broker                       |
|                 (Apache Kafka / RabbitMQ / Azure Event Hubs)                |
+-----------------------------------------------------------------------------+
                 │                                                      │
                 ▼                                                      ▼
   +──────────────────────────+                           +─────────────────────────+
   |   Notification Service   |                           |    Analytics / CQRS     |
   |  (Background Worker)     |                           |   (Elasticsearch / DB)  |
   +──────────────────────────+                           +─────────────────────────+

Core Pillars of Microservices

If you want your distributed architecture to survive in production, there are six non-negotiable principles you need to embrace:

1. Domain-Driven Bounded Contexts (DDD): Split your services along real business capabilities (e.g., Billing, Catalog, Fulfillment), never by technical layers (UI Service, Business Logic Service, Database Service).
2. Decentralized Data Ownership: If Service A writes directly to Service B’s database tables, you don’t have microservices—you have a distributed monolith with double the network latency. Every service must strictly encapsulate its own storage.
3. Smart Endpoints, Dumb Pipes: Put all business logic, validation, and domain rules inside your services. Your message broker (Kafka, RabbitMQ) should be a dumb, high-speed pipe that only transports messages.
4. Design for Failure from Day One: In a network of 20 services, something is always failing. A database is slow, a pod restarted, or a network switch dropped packets. Your code must use timeouts, retries with backoff, circuit breakers, and fallbacks.
5. Independent Deployability: If releasing a new feature in the Order Service requires you to simultaneously deploy the Payment Service and Inventory Service, your boundaries are wrong. Services must be deployable independently at any time.
6. Pragmatic Polyglot Freedom: Choose the right tool for the job. You can build your high-throughput transactional APIs in .NET 10 / C#, your AI/ML recommendation pipelines in Python, and lightweight websocket handlers in Node.js.

Monolith vs Modular Monolith vs Microservices

Before jumping into microservices, look at where your application actually sits on the architectural spectrum:

Types and Subtypes of Microservices

In enterprise systems, services naturally fall into specialized archetypes based on what they do, how they communicate, and how they store data:

Microservices Architecture Taxonomy
├── 1. Core / Domain Services
│   ├── 1.1 Entity & Aggregate Services
│   ├── 1.2 Domain Logic & Calculation Engines
│   └── 1.3 Master Data & Catalog Services
├── 2. Composite & Orchestration Services
│   ├── 2.1 API Aggregator / Scatter-Gather Services
│   ├── 2.2 Chained Processing Pipelines
│   └── 2.3 Workflow & Saga Orchestrators
├── 3. Edge & Ingress Services
│   ├── 3.1 API Gateway
│   ├── 3.2 Backend for Frontend (BFF)
│   └── 3.3 Edge Cache & Content Routers
├── 4. Asynchronous Workers & Stream Processors
│   ├── 4.1 Event Stream Consumers
│   ├── 4.2 Transactional Outbox & CDC Relays
│   ├── 4.3 Notification & Webhook Dispatchers
│   └── 4.4 Scheduled Batch & Cron Workers
├── 5. Infrastructure & Cross-Cutting Services
│   ├── 5.1 Identity & Access Management (IAM / OAuth2)
│   ├── 5.2 Centralized Configuration & Secret Providers
│   ├── 5.3 Service Registry & Discovery Directory
│   └── 5.4 Centralized Audit & Telemetry Collectors
└── 6. Read-Model & Analytical Services (CQRS / Data Mesh)
    ├── 6.1 CQRS Materialized Read Projections
    ├── 6.2 Full-Text Search Engines
    └── 6.3 Real-Time Stream Analytics & Metrics

1. Core / Domain Services

These are the heart of your system. They represent business entities and encapsulate core business rules.

• 1.1 Entity & Aggregate Services:
  • What they do: Manage transactional state and business rules for a primary aggregate root (e.g., OrderService, PaymentService, CustomerService).
  • Tech stack: ASP.NET Core API, Entity Framework Core, PostgreSQL / SQL Server.
  • Communication: Synchronous gRPC or REST for command execution; asynchronous domain events for publishing state changes.
• 1.2 Domain Logic & Calculation Engines:
  • What they do: Compute complex algorithms without storing heavy mutable state (e.g., DynamicPricingEngine, TaxCalculationService, FraudDetectionService).
  • Characteristics: Stateless, compute-intensive, horizontally auto-scalable based on CPU/RAM load.
• 1.3 Master Data & Reference Services:
  • What they do: Serve slowly changing reference data used across the whole enterprise (e.g., ProductCatalogService, CurrencyExchangeService, ZipCodeLookupService).
  • Characteristics: Extremely read-heavy, paired with distributed caching (Redis).

2. Composite & Orchestration Services

When a single business operation spans multiple domain services, composite services coordinate the workflow.

• 2.1 API Aggregator / Scatter-Gather Services:
  • What they do: Receive one request from a client, fan out parallel calls to 3 or 4 downstream domain services, merge the results into a single clean JSON payload, and return it.
  • Example: A CustomerDashboardAggregator that calls UserService (profile info), OrderService (recent 5 orders), and RewardsService (loyalty points balance) simultaneously.
• 2.2 Chained Processing Pipelines:
  • What they do: Pass the output of Service A directly as input to Service B, then Service C in a strictly ordered sequence (e.g., OrderPipeline: Validate $\rightarrow$ Apply Discount $\rightarrow$ Hold Inventory $\rightarrow$ Charge Card).
• 2.3 Workflow & Saga Orchestrators:
  • What they do: Maintain state machines for complex distributed transactions, issuing commands to participating services and triggering compensating rollback actions if any step fails (e.g., CheckoutSagaOrchestrator).

3. Edge & Ingress Services

These live at the perimeter of your network and act as the single front door for all client traffic.

• 3.1 API Gateway:
  • What they do: Accept incoming requests from web and mobile clients, handle SSL termination, authenticate JWT tokens, enforce IP rate limits, and route requests to internal Kubernetes services (e.g., YARP, Ocelot, Envoy, Kong).
• 3.2 Backend for Frontend (BFF):
  • What they do: Provide dedicated gateways tailored specifically to the needs of different client applications. Your iOSMobileBFF might return lightweight, compact JSON payloads to save battery and mobile bandwidth, while your WebAdminBFF returns rich data tables.
• 3.3 Edge Cache & Router:
  • What they do: Terminate requests at cloud edge locations (Cloudflare, Azure Front Door, AWS CloudFront) to serve cached responses with sub-10ms latency.

4. Asynchronous Workers & Stream Processors

Headless background workers that do not expose public HTTP endpoints. They listen to message brokers and process jobs asynchronously.

• 4.1 Event Stream Consumers:
  • What they do: Consume high-throughput message topics from Apache Kafka or RabbitMQ, update local read-models, or trigger downstream business processes.
• 4.2 Transactional Outbox & CDC Relays:
  • What they do: Read the Outbox table or tail database transaction logs (using Debezium) to reliably publish domain events to the message broker without risking dual-write inconsistencies.
• 4.3 Notification & Webhook Dispatchers:
  • What they do: Handle integrations with third-party providers (Twilio for SMS, SendGrid for Email, Apple APNs for Push) with built-in retry queues and dead-letter handling.
• 4.4 Scheduled Batch & Cron Workers:
  • What they do: Execute recurring business tasks such as nightly reconciliation runs, subscription renewal processing, and old data archival sweeps.

5. Infrastructure & Cross-Cutting Services

Platform-level utilities that provide security, configuration, and telemetry to all domain services.

• 5.1 Identity & Access Management (IAM / OAuth2 / OIDC):
  • What they do: Centralize user login, issue signed JWT access tokens, handle refresh tokens, and manage role-based access control (e.g., Keycloak, Duende IdentityServer, Microsoft Entra ID).
• 5.2 Centralized Configuration & Secret Providers:
  • What they do: Inject environment variables, feature flags, and encrypted connection strings into services at runtime without hardcoding them in git (e.g., Azure App Configuration + Key Vault, HashiCorp Vault).
• 5.3 Service Registry & Discovery Directory:
  • What they do: Keep track of the dynamically changing IP addresses and ports of running microservice containers (e.g., Kubernetes CoreDNS, Consul).
• 5.4 Centralized Audit & Telemetry Collectors:
  • What they do: Aggregate structured JSON logs, metrics, and distributed traces from all pods (e.g., OpenTelemetry Collector, Prometheus, Grafana Loki, Seq).

6. Read-Model & Analytical Services (CQRS / Data Mesh)

Services designed exclusively for high-speed queries, search, and business intelligence without locking write databases.

• 6.1 CQRS Materialized Read Projections:
  • What they do: Listen to domain events and maintain pre-joined, denormalized read stores (Redis, MongoDB) so UI screens can fetch complete views in a single lookup.
• 6.2 Full-Text Search Engines:
  • What they do: Index product catalogs, blog articles, and customer records into Elasticsearch or OpenSearch to provide autocomplete, fuzzy matching, and multi-faceted filtering.
• 6.3 Real-Time Stream Analytics & Metrics:
  • What they do: Ingest continuous event streams to calculate real-time analytics, such as live dashboard metrics, active shopping cart counts, or fraud anomaly detection.

Master Matrix: Which Pattern Solves Which Issue

Here is your comprehensive cheat sheet mapping distributed systems challenges to their proven design patterns:

Deep-Dive: Decomposition Patterns

Decomposing a system is where most teams get stuck. If you draw your service boundaries incorrectly, you end up with the worst architectural pattern in software engineering: the distributed monolith (all the network latency and deployment coordination of microservices, with all the coupling of a monolith).

Decompose by Business Capability vs Subdomain (DDD)

graph TD
    subgraph Monolith["Legacy Monolithic Enterprise System"]
        M1[Order Module]
        M2[Customer Module]
        M3[Billing Module]
        M4[Warehouse Module]
    end

    subgraph DDD["Decomposed by Bounded Contexts (DDD)"]
        S1["Order Bounded Context<br/>(Core Subdomain)"]
        S2["Customer Bounded Context<br/>(Supporting Subdomain)"]
        S3["Payment & Billing<br/>(Generic Subdomain)"]
        S4["Fulfillment & Inventory<br/>(Supporting Subdomain)"]
    end

    Monolith -->|Decompose using Event Storming| DDD

• Decompose by Business Capability: Look at what the company actually does (e.g., Order Processing, Inventory Warehousing, Invoicing).
• Decompose by Subdomain (Domain-Driven Design): Classify your domains by strategic value:
  1. Core Subdomain: The unique software differentiator that makes your company money (e.g., proprietary matching algorithm).
  2. Supporting Subdomain: Custom business features that support the core domain (e.g., Customer Loyalty Portal).
  3. Generic Subdomain: Standard business functions you could theoretically buy off the shelf (e.g., Authentication, Email Notifications, Invoicing).

Deep-Dive: Data Management & Distributed Transactions

In microservices, you cannot use SQL joins across services. You must manage distributed consistency.

1. The Saga Pattern (Orchestration vs Choreography)

When an e-commerce order is placed, three distinct services must commit transactions:

1. OrderService (Create order in Pending state)
2. PaymentService (Authorize and charge credit card)
3. InventoryService (Reserve stock)

sequenceDiagram
    autonumber
    actor Customer
    participant Gateway as API Gateway
    participant Orchestrator as Order Saga Orchestrator
    participant OrderSvc as Order Service
    participant PaymentSvc as Payment Service
    participant InventorySvc as Inventory Service

    Customer->>Gateway: POST /api/orders (Checkout)
    Gateway->>Orchestrator: Start OrderSaga
    Orchestrator->>OrderSvc: 1. CreatePendingOrder()
    OrderSvc-->>Orchestrator: OrderCreated (Pending)

    Orchestrator->>PaymentSvc: 2. ProcessPayment()
    alt Payment Succeeded
        PaymentSvc-->>Orchestrator: PaymentCaptured
        Orchestrator->>InventorySvc: 3. ReserveInventory()
        alt Inventory Succeeded
            InventorySvc-->>Orchestrator: InventoryReserved
            Orchestrator->>OrderSvc: 4. CompleteOrder()
            OrderSvc-->>Orchestrator: OrderConfirmed
            Orchestrator-->>Gateway: 200 OK (Order Placed)
        else Out of Stock (Failure)
            InventorySvc-->>Orchestrator: OutOfStockError
            Note over Orchestrator,PaymentSvc: Compensating Transaction Triggered!
            Orchestrator->>PaymentSvc: 4a. RefundPayment()
            PaymentSvc-->>Orchestrator: PaymentRefunded
            Orchestrator->>OrderSvc: 4b. CancelOrder()
            OrderSvc-->>Orchestrator: OrderCancelled
            Orchestrator-->>Gateway: 400 Bad Request (Order Failed)
        end
    else Payment Declined (Failure)
        PaymentSvc-->>Orchestrator: PaymentFailed
        Orchestrator->>OrderSvc: CancelOrder()
        Orchestrator-->>Gateway: 402 Payment Required
    end

2. The Transactional Outbox Pattern + Change Data Capture (CDC)

When updating a database and publishing an event, the Dual-Write Problem occurs if your database update succeeds but the network blips before publishing to Kafka.

The Transactional Outbox Pattern solves this by writing the entity update and the event record into the same database within a single local ACID transaction.

flowchart LR
    subgraph OrderServicePod["Order Microservice"]
        API[API Controller] -->|1. Local DB Transaction| DB[(Private SQL Database)]
        subgraph DB["Private Database"]
            T1[Orders Table]
            T2[Outbox Table]
        end
    end

    subgraph Relay["Message Relay Engine"]
        Debezium["CDC Debezium / Background Worker"]
    end

    subgraph Broker["Event Streaming Platform"]
        Kafka["Apache Kafka Topic: order.events"]
    end

    subgraph Downstream["Downstream Services"]
        EmailSvc["Email Notification Service"]
        AnalyticsSvc["CQRS Read Model"]
    end

    DB -->|2. Transaction Log / Polling| Debezium
    Debezium -->|3. Guaranteed At-Least-Once Delivery| Kafka
    Kafka -->|4. Consume & Process| EmailSvc
    Kafka -->|4. Project Read Model| AnalyticsSvc

Deep-Dive: Reliability & Resiliency Patterns

In distributed systems, network partitions and service outages are expected events. Resiliency patterns ensure that failures remain isolated.

The Circuit Breaker State Machine

stateDiagram-v2
    [*] --> Closed

    Closed --> Open: Failure rate exceeds threshold<br/>(e.g., 5 consecutive 500 errors)
    note right of Closed
        Normal Operation:
        All requests pass through to downstream service.
        Success and failure counters tracked.
    end note

    Open --> HalfOpen: Cooldown duration expires<br/>(e.g., after 30 seconds)
    note right of Open
        Failing Fast:
        Requests immediately return Fallback or 503.
        No network calls made downstream.
    end note

    HalfOpen --> Closed: Trial requests succeed<br/>(Downstream is healthy)
    HalfOpen --> Open: Any trial request fails<br/>(Downstream still broken)
    note right of HalfOpen
        Testing Health:
        Limited trial requests allowed through.
    end note

Practical .NET Core Code Examples

1. Transactional Outbox Pattern in ASP.NET Core & EF Core

Outbox Message Entity & DbContext Setup

using System.Text.Json;
using Microsoft.EntityFrameworkCore;

public class OutboxMessage
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public string EventType { get; set; } = string.Empty;
    public string Payload { get; set; } = string.Empty;
    public DateTime CreatedOnUtc { get; set; } = DateTime.UtcNow;
    public DateTime? ProcessedOnUtc { get; set; }
    public string? ErrorMessage { get; set; }
}

public class OrderDbContext : DbContext
{
    public OrderDbContext(DbContextOptions<OrderDbContext> options) : base(options) { }

    public DbSet<Order> Orders => Set<Order>();
    public DbSet<OutboxMessage> OutboxMessages => Set<OutboxMessage>();

    public async Task SaveOrderWithOutboxAsync<TEvent>(Order order, TEvent domainEvent)
    {
        // 1. Add the domain entity
        Orders.Add(order);

        // 2. Add the outbox record in the EXACT same local ACID transaction
        OutboxMessages.Add(new OutboxMessage
        {
            EventType = typeof(TEvent).Name,
            Payload = JsonSerializer.Serialize(domainEvent)
        });

        // 3. Commit both atomically
        await SaveChangesAsync();
    }
}

Outbox Background Publisher Worker

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.EntityFrameworkCore;

public class OutboxPublisherWorker : BackgroundService
{
    private readonly IServiceProvider _serviceProvider;
    private readonly IMessageProducer _messageProducer;
    private readonly ILogger<OutboxPublisherWorker> _logger;

    public OutboxPublisherWorker(
        IServiceProvider serviceProvider,
        IMessageProducer messageProducer,
        ILogger<OutboxPublisherWorker> logger)
    {
        _serviceProvider = serviceProvider;
        _messageProducer = messageProducer;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                using var scope = _serviceProvider.CreateScope();
                var dbContext = scope.ServiceProvider.GetRequiredService<OrderDbContext>();

                // Fetch unprocessed outbox messages in batches
                var pendingMessages = await dbContext.OutboxMessages
                    .Where(m => m.ProcessedOnUtc == null)
                    .OrderBy(m => m.CreatedOnUtc)
                    .Take(20)
                    .ToListAsync(stoppingToken);

                foreach (var message in pendingMessages)
                {
                    try
                    {
                        // Publish to Kafka / RabbitMQ
                        await _messageProducer.PublishAsync(message.EventType, message.Payload, stoppingToken);
                        message.ProcessedOnUtc = DateTime.UtcNow;
                    }
                    catch (Exception ex)
                    {
                        _logger.LogError(ex, "Failed to publish Outbox message {Id}", message.Id);
                        message.ErrorMessage = ex.Message;
                    }
                }

                if (pendingMessages.Count > 0)
                {
                    await dbContext.SaveChangesAsync(stoppingToken);
                }
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error processing outbox messages");
            }

            // Polling interval
            await Task.Delay(TimeSpan.FromSeconds(2), stoppingToken);
        }
    }
}

2. Resiliency Pipeline (Polly v8 in .NET Core)

Configure a resilient HTTP client combining Retry with Exponential Backoff + Circuit Breaker + Timeout:

using Polly;
using Polly.CircuitBreaker;
using Polly.Retry;
using Polly.Timeout;

var builder = WebApplication.CreateBuilder(args);

// Register HttpClient with Polly Resilience Pipeline
builder.Services.AddHttpClient("PaymentClient", client =>
{
    client.BaseAddress = new Uri("https://payment-service.internal/");
})
.AddResilienceHandler("custom-resilience-pipeline", pipelineBuilder =>
{
    // 1. Timeout Policy (Outer: Limit overall operation time)
    pipelineBuilder.AddTimeout(new TimeoutStrategyOptions
    {
        Timeout = TimeSpan.FromSeconds(5)
    });

    // 2. Retry Policy with Exponential Backoff and Jitter
    pipelineBuilder.AddRetry(new RetryStrategyOptions<HttpResponseMessage>
    {
        MaxRetryAttempts = 3,
        BackoffType = DelayBackoffType.Exponential,
        UseJitter = true,
        Delay = TimeSpan.FromMilliseconds(500),
        ShouldHandle = new PredicateBuilder<HttpResponseMessage>()
            .Handle<HttpRequestException>()
            .Handle<TimeoutRejectedException>()
            .HandleResult(response => (int)response.StatusCode >= 500)
    });

    // 3. Circuit Breaker Policy
    pipelineBuilder.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5, // Break if 50% of requests fail
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 8,
        BreakDuration = TimeSpan.FromSeconds(30),
        OnOpened = args =>
        {
            Console.WriteLine($"[ALERT] Circuit Breaker opened for {args.BreakDuration.TotalSeconds}s!");
            return ValueTask.CompletedTask;
        },
        OnClosed = _ =>
        {
            Console.WriteLine("[INFO] Circuit Breaker closed. Traffic restored.");
            return ValueTask.CompletedTask;
        }
    });
});

3. YARP (Yet Another Reverse Proxy) API Gateway Configuration

ASP.NET Core’s production-grade reverse proxy configuration in appsettings.json:

{
  "ReverseProxy": {
    "Routes": {
      "orders-route": {
        "ClusterId": "orders-cluster",
        "Match": {
          "Path": "/api/orders/{**catch-all}"
        },
        "Transforms": [
          { "PathPattern": "{**catch-all}" }
        ]
      },
      "payments-route": {
        "ClusterId": "payments-cluster",
        "Match": {
          "Path": "/api/payments/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "orders-cluster": {
        "Destinations": {
          "order-instance-1": { "Address": "http://orders-svc-1:8080" },
          "order-instance-2": { "Address": "http://orders-svc-2:8080" }
        },
        "LoadBalancingPolicy": "RoundRobin"
      },
      "payments-cluster": {
        "Destinations": {
          "payment-instance-1": { "Address": "http://payments-svc:8080" }
        }
      }
    }
  }
}

Interactive Architecture Checklist

Use this checklist to track pattern implementation across your microservices architecture:

Decision Framework & Best Practices

When designing microservices, follow these core architectural rules:

1. Start with a Modular Monolith First: Unless your team size exceeds 20-30 engineers or you have distinct scaling requirements, starting with a well-structured modular monolith is often the safest path.
2. Never Share Databases Between Services: A shared database couples services, breaking independent deployability and invalidating microservice benefits.
3. Embrace Asynchronous Communication by Default: Use asynchronous events (Kafka, RabbitMQ) for inter-service communication whenever immediate response data is not needed.
4. Make Every Message Consumer Idempotent: In distributed systems with retries, duplicate messages will arrive. Ensure consumers handle duplicate deliveries safely using unique message IDs.
5. Enforce Observability on Day One: Standardize OpenTelemetry traces (traceparent), structured JSON logs, and Prometheus metrics across all services before going to production.
6. Prefer Saga Orchestration for Complex Business Workflows: For multi-step workflows with strict auditability and compensating actions, orchestration simplifies tracking and error recovery.