میکروسرویس: مبانی، مرزبندی و کِی/چراMicroservices: Foundations, Boundaries & When/Why

Let me open with a confession many seniors learn too late: microservices is not an architectural decision, it is an organizational one. You don't split a system because it's "cleaner"; you split it because your teams, your deploy cadence, and the asymmetric scale of different parts of the system force you to. If you take only one sentence from this chapter, you're already ahead of half the market.

This chapter isn't just "what is a microservice." You're going to learn to judge it like a senior: see its real cost, find the right boundary with DDD, know when a monolith is the more mature choice, and defend your decision in an interview with numbers and trade-offs instead of buzzwords.

1) A microservice in one picture

Microservices means: instead of one application holding all the business logic in one process and usually one database, you split the system into a set of small, independent, separately deployable services, each of which:

• Owns one specific business capability (e.g. "orders", "payment", "inventory").
• Owns its own database, which no one else touches directly.
• Talks to others over a network API (HTTP/gRPC) or messages on a broker.
• Is developed, deployed, and operated by one team and released independently of the rest.

That last phrase — "released independently" — is the heart of it. If deploying service A forces you to deploy service B at the same time, you don't have microservices; you have a distributed monolith, which is the worst of both worlds.

2) Three options, not two

The industry loves to see the world as a binary: "bad monolith" vs. "modern microservices." That's a false dichotomy. There's a third option that often wins in practice: the modular monolith.

Monolith: one deployment unit

A monolith means all code in one codebase, one build unit, one running process. That's not "bad" — it has unmatched operational simplicity: one log, one database transaction, one thing to deploy, and a call between modules is a method call inside the same JVM (nanoseconds, no network, no serialization, no network errors).

Modular monolith: one deployment unit, hard boundaries

A modular monolith is still a monolith, but with module boundaries the compiler enforces. Modules talk only through each other's public API, never touch each other's database tables, and have controlled dependencies — exactly the boundary discipline of microservices, without the network cost.

In the Spring ecosystem, Spring Modulith exists precisely for this: it verifies module boundaries at test time, manages inter-module events, and turns your tests red if a module reaches into another module's internals.

// A Spring Modulith test that guarantees module boundaries
import org.springframework.modulith.core.ApplicationModules;
import org.junit.jupiter.api.Test;

class ModularityTests {

    ApplicationModules modules = ApplicationModules.of(EcommerceApplication.class);

    @Test
    void verifiesModularStructure() {
        // If the order module reaches into the payment module's internal classes,
        // this test fails — the boundary is enforced by the build, not by code review
        modules.verify();
    }
}

Comparison table

3) The real cost of microservices (that the blog posts skip)

This is where the senior separates from the junior. The junior counts the benefits; the senior counts the costs and asks "is it worth it?"

a) Operational cost multiplies

A monolith means one pipeline, one dashboard, one logging policy. With 20 microservices you now have 20 pipelines, 20 sets of metrics, version management for 20 services, and coordination of 20 release schedules. Without a mature platform (Kubernetes, automated CI/CD, centralized observability), microservices will crush you under operational load.

b) Distributed debugging is hell

In a monolith, when something breaks you get one stack trace showing everything top to bottom. In microservices, a user request goes from the gateway to service A, to service B, to the broker, to service C. When it slows down or breaks, you have 5 separate logs on 5 machines with no connection to each other — unless you took distributed tracing seriously from day one.

c) Distributed data is the hard wall

In a monolith one @Transactional guarantees your whole unit of work with ACID: everything commits or nothing does. When "order" and "payment" live in two separate databases, you no longer have a global transaction. You must live with eventual consistency, patterns like Saga and transactional outbox, and compensation logic. This is one of the biggest mental leaps in the move to microservices.

d) The network lies: the eight fallacies of distributed computing

Every method call that was a nanosecond in a monolith and never failed becomes, in microservices, a network call that can take milliseconds and can fail. That change changes everything: you must design every interaction assuming failure.

4) When NOT to go micro (more important than when to go)

Remember Martin Fowler's famous line: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up. Almost all the cases where a system was built as a microservice system from scratch have ended up in serious trouble." This is called "Monolith First" and is one of the most mature pieces of advice in the field.

5) Conway's law: why your architecture mirrors your org

The practical consequence for microservices is huge: if your service boundaries aren't aligned with your team boundaries, you will fail. If one feature always drags in three teams and three services, coordination cost will kill you.

6) Correct boundaries with DDD: bounded context

The biggest mistake in microservices is drawing technical boundaries instead of business boundaries. If your services have names like UserService, DatabaseService, ValidationService, you're splitting by technical layer — and that's almost always wrong, because every feature crosses multiple layers and thus drags in multiple services at once.

The right method comes from Domain-Driven Design (DDD).

A bounded context is a boundary within which one domain model and one shared language (ubiquitous language) have a precise, unique meaning. A good microservice boundary usually falls exactly on a bounded context. Inside that boundary, Customer means one thing; outside it, another service has its own model and translates via API/events (DDD calls this an anti-corruption layer).

How to find the boundaries

• Event Storming: sit with business stakeholders and stick domain events on the wall (OrderPlaced, PaymentAuthorized, ItemShipped). Clusters of events usually reveal bounded contexts.
• Decompose by business capability: "order taking", "payment", "inventory", "shipping" — not by nouns or layers.
• Subdomains: separate the core (your competitive advantage) from supporting and generic subdomains (e.g. sending email, which you can just buy).

7) Data ownership: each service, its own database

This is probably the hardest and most important rule of microservices: no two services share a database, and no service touches another service's tables directly.

So each service owns its own database (which can be a different technology — "polyglot persistence": the order service on PostgreSQL, the search service on Elasticsearch, the cart service on Redis). But this creates a big problem: how do you keep cross-service data in sync without a global transaction?

The Transactional Outbox pattern

Problem: when an order is placed you want to both save it in your own database and publish an OrderPlaced event to Kafka. If you write to the DB first, then to Kafka, and crash in between, the event is lost (the dual-write problem). Solution: write the event in the same database transaction into an outbox table; then a separate process reads it and sends it to the broker.

Let's look at the outbox table in both dialects you work with, because they have real differences.

-- PostgreSQL
CREATE TABLE outbox (
    id          UUID         PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregate   VARCHAR(64)  NOT NULL,
    event_type  VARCHAR(128) NOT NULL,
    payload     JSONB        NOT NULL,
    created_at  TIMESTAMPTZ  NOT NULL DEFAULT now(),
    published   BOOLEAN      NOT NULL DEFAULT false
);
-- Batch-read unpublished events with a row lock so parallel workers don't double-process:
SELECT id, event_type, payload
FROM   outbox
WHERE  published = false
ORDER  BY created_at
LIMIT  100
FOR UPDATE SKIP LOCKED;

-- Oracle (19c/23ai)
CREATE TABLE outbox (
    id          RAW(16)        DEFAULT SYS_GUID() PRIMARY KEY,
    aggregate   VARCHAR2(64)   NOT NULL,
    event_type  VARCHAR2(128)  NOT NULL,
    payload     CLOB           NOT NULL,   -- or JSON type in 21c and later
    created_at  TIMESTAMP      DEFAULT SYSTIMESTAMP NOT NULL,
    published   NUMBER(1)      DEFAULT 0 NOT NULL  -- Oracle had no native boolean
);
-- Oracle equivalent of pagination + skip-lock:
SELECT id, event_type, payload
FROM   outbox
WHERE  published = 0
ORDER  BY created_at
FETCH FIRST 100 ROWS ONLY
FOR UPDATE SKIP LOCKED;

Cross-service data exchange usually takes two shapes: API composition (a service or the gateway calls several services and stitches the responses) or CQRS with a read replica (each service keeps a local read-only copy of the data it needs, fed by events, so it doesn't have to call another service on every request).

8) The Twelve-Factor App

The twelve factors are a set of principles for building services that behave well in the cloud — scale, deploy painlessly, and stay portable. For Spring microservices, the most important ones:

• Config in the environment, not in code (Factor III): secrets and URLs come from environment variables or a config server, not hard-code. In Spring: application.yml + env vars + Spring Cloud Config.
• Backing services as swappable resources (IV): database, broker, cache all connected via a URL in config, so they can be swapped with no code change.
• Stateless processes (VI): the service keeps no in-memory state that's needed between requests; state goes to the database/cache. This is the prerequisite for horizontal scaling.
• Port binding (VII): the service embeds its own server (Spring Boot with embedded Tomcat/Netty) and listens on a port.
• Concurrency via processes (VIII): for more load, spin up more instances (scale horizontally), not one giant instance.
• Disposability (IX): start fast, shut down gracefully (Spring Boot: server.shutdown=graceful).
• Logs as event streams (XI): log to stdout, not to a file; the platform collects it.

9) A typical Java/Spring topology

Now let's draw a real map: a sample e-commerce system with the standard components of the Spring Cloud ecosystem.

Architecture diagram: the request path from client to services and infrastructure (client → gateway → services → data/broker).

flowchart TD
  Client[Web / Mobile Client] --> GW[API Gateway]
  GW --> OrderSvc[Order Service]
  GW --> PaymentSvc[Payment Service]
  GW --> CatalogSvc[Catalog Service]
  OrderSvc --> OrderDB[(Order DB)]
  PaymentSvc --> PayDB[(Payment DB)]
  CatalogSvc --> CatalogDB[(Catalog DB)]
  OrderSvc -- OrderPlaced --> Broker[(Kafka Broker)]
  Broker --> PaymentSvc
  Broker --> ShipSvc[Shipping Service]
  Registry{{Service Registry}} -.discovery.- GW
  Registry -.discovery.- OrderSvc
  Registry -.discovery.- PaymentSvc
  Config[[Config Server]] -.config.- OrderSvc
  Config -.config.- PaymentSvc

Key components:

• API Gateway: the single entry door. It centralizes routing, authentication, rate limiting, and protocol translation. In Spring: Spring Cloud Gateway.
• Service Registry / Discovery: services don't have fixed addresses (in Kubernetes they move constantly). The registry is like a "live phone book": each service registers itself and others find it by name. Like Eureka or Consul.
• Config Server: centralized, versioned configuration for all services. Like Spring Cloud Config or Consul KV.
• Message Broker: for asynchronous, event-driven communication. Like Kafka or RabbitMQ.
• A database per service: separate, per the data-ownership rule.

Code: a gateway that routes via discovery

pom.xml (key parts):

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway-server-webflux</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!-- Required to resolve lb:// from the registry -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

application.yml on the gateway:

spring:
  application:
    name: api-gateway
  cloud:
    gateway:
      discovery:
        locator:
          enabled: false   # In production define routes explicitly, not automatically
      routes:
        - id: order-service
          uri: lb://ORDER-SERVICE      # lb:// means find via registry and load-balance
          predicates:
            - Path=/api/orders/**
          filters:
            - name: CircuitBreaker
              args:
                name: orderCB
                fallbackUri: forward:/fallback/orders
        - id: catalog-service
          uri: lb://CATALOG-SERVICE
          predicates:
            - Path=/api/catalog/**

eureka:
  client:
    service-url:
      defaultZone: http://discovery:8761/eureka/

Code: a service that registers itself and pulls config

On the order service, application.yml:

spring:
  application:
    name: order-service
  config:
    import: "optional:configserver:http://config:8888"  # read from Spring Cloud Config

server:
  port: 0            # random port; the registry knows the real address
  shutdown: graceful # finish in-flight requests before shutting down

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  tracing:
    sampling:
      probability: 1.0   # usually lower in production, e.g. 0.1

eureka:
  client:
    service-url:
      defaultZone: http://discovery:8761/eureka/

The main class and a resilient client:

@SpringBootApplication
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

// Inter-service call by logical name (not IP), hardened with Resilience4j
@Service
class PaymentClient {

    private final RestClient restClient;

    PaymentClient(RestClient.Builder builder) {
        // "http://payment-service" resolves to a real instance via the load balancer
        this.restClient = builder.baseUrl("http://payment-service").build();
    }

    @CircuitBreaker(name = "payment", fallbackMethod = "fallback")
    @Retry(name = "payment")
    public PaymentResult authorize(PaymentRequest req) {
        return restClient.post()
            .uri("/authorizations")
            .body(req)
            .retrieve()
            .body(PaymentResult.class);
    }

    // Called when the circuit is open or all retries failed
    private PaymentResult fallback(PaymentRequest req, Throwable ex) {
        return PaymentResult.pending(req.orderId());  // graceful degradation
    }
}

The end-to-end sequence of a request

Sequence diagram: placing an order with a mix of a synchronous call and an asynchronous event.

sequenceDiagram
    participant C as Client
    participant G as Gateway
    participant O as Order Service
    participant P as Payment Service
    participant K as Kafka
    participant S as Shipping Service
    C->>G: POST /api/orders
    G->>O: route (lb + traceId)
    O->>O: persist Order (status=PENDING) + outbox row
    O-->>K: OrderPlaced (via outbox/CDC)
    O-->>G: 202 Accepted
    G-->>C: 202 Accepted
    K->>P: OrderPlaced
    P->>P: authorize payment
    P-->>K: PaymentAuthorized
    K->>O: PaymentAuthorized -> status=CONFIRMED
    K->>S: PaymentAuthorized -> schedule shipment

Notice the response to the user (202 Accepted) returns before payment completes. That's deliberate: the system is asynchronous and eventually consistent. The user gets an immediate answer, and the rest of the work proceeds in the background via events. This pattern gives scale and resilience, but it disturbs the monolith-shaped mind because things are no longer "right now and atomic."

10) Communication patterns: synchronous vs. asynchronous

State diagram: the lifecycle of a circuit breaker (closed → open → half-open).

stateDiagram-v2
    [*] --> Closed
    Closed --> Open: failure rate > threshold
    Open --> HalfOpen: after wait duration
    HalfOpen --> Closed: trial calls succeed
    HalfOpen --> Open: trial calls fail

In the Closed state everything is normal and calls pass through. When the failure rate crosses the threshold, it goes to Open and all calls immediately hit the fallback (we don't hammer D, giving it a chance to recover). After a wait period, it goes to Half-Open and sends a few trial calls; if they succeed, back to Closed; if not, Open again. In Spring you implement this with Resilience4j.

11) Migration with the Strangler Fig pattern

Almost no one has successfully built microservices from scratch. The right path is to gradually break up an existing monolith. The standard pattern is the Strangler Fig.

The practical steps:

1. Put a gateway/proxy in front of the monolith so all traffic goes through it (with no behavior change).
2. Pick a low-risk, high-value bounded context (e.g. "notifications" or "catalog").
3. Build that capability as a new service, and in the gateway route it to the new service (not the monolith).
4. Sync that domain's data via CDC/events so the monolith and the new service stay consistent during the transition.
5. Repeat; one slice at a time, until the monolith shrinks to a small core or disappears entirely.

Diagram: a routing layer splitting traffic between the monolith and the extracted service (strangler routing).

flowchart LR
  Client --> Router[Strangler Facade / Gateway]
  Router -->|/catalog/**| NewCatalog[New Catalog Service]
  Router -->|everything else| Monolith[Legacy Monolith]
  NewCatalog --> CatalogDB[(Catalog DB)]
  Monolith --> LegacyDB[(Legacy DB)]
  Monolith -. sync via CDC .-> CatalogDB

12) Team ownership: "You build it, you run it"

The organizational philosophy of microservices is summed up in one line from Werner Vogels (Amazon's CTO): "You build it, you run it." The team that builds the service also runs and supports it in production — they carry the pager too.

Each service has a clear owner and a clear contract with its consumers. To keep one team's change from breaking another, teams use contract testing (e.g. Spring Cloud Contract or Pact): the consumer writes its API expectations as tests, and the producer's pipeline verifies that contract. This way an incompatible change is caught before production, not after.

13) How a senior justifies the choice

In an interview or a design meeting, the difference between junior and senior is in how they reason. The junior says "microservices scales better." The senior brings a trade-off framework:

The key sentence you should be able to say in an interview: "Microservices is an organizational optimization paid for with technical complexity. I buy that complexity when its organizational benefit (team autonomy, independent scale, fault isolation) outweighs its cost — and until then I build a good modular monolith that keeps my migration path open." This sentence shows you understand the trade-off, not just the buzzword.

Interview questions