What makes a microservice truly independently deployable

Independent deployment test:
Question: Can I deploy this service alone, right now, without a meeting?
Answer YES -> microservice
Answer NO  -> distributed monolith

# .github/workflows/payment-service.yml
name: Payment Service CI/CD
on:
  push:
    branches: [main]
    paths: ['payment-service/**']  # only triggers for this service

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: cd payment-service && mvn clean package
      - name: Test
        run: cd payment-service && mvn verify
      - name: Deploy
        run: kubectl apply -f payment-service/k8s/

Expected behavior:
Commit to payment-service/ -> only payment-service pipeline runs
Account Service is NOT rebuilt, NOT redeployed, NOT affected.

package com.bank.payment.model;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Version;
import java.math.BigDecimal;
import java.time.Instant;

@Entity
public class Payment {

    @Id
    private String paymentId;
    private String fromAccountId;  // ID reference only, NOT a JPA relation
    private String toAccountId;    // ID reference only, NOT a JPA relation
    private BigDecimal amount;
    private String status;
    private Instant createdAt;
    @Version
    private Long version;

    // Payment Service owns this table exclusively.
    // Account Service NEVER queries this table.
    // If Account Service needs payment data, it calls Payment Service API
    // or consumes payment-events from Kafka.
}

WRONG: Account Service queries Payment Service's database directly.
  -> Schema change in payments table breaks Account Service.
  -> Both must deploy together.

CORRECT: Account Service calls Payment Service API or consumes events.
  -> Schema changes are internal. Only Payment Service redeploys.

package com.bank.payment.dto;

import java.math.BigDecimal;

// Version 1: original request
public record TransferRequestV1(
    String fromAccountId,
    String toAccountId,
    BigDecimal amount
) {}

// Version 2: added optional reference field
// Old clients omit it -> still works (backward compatible)
public record TransferRequestV2(
    String fromAccountId,
    String toAccountId,
    BigDecimal amount,
    String reference  // optional, defaults to null
) {}

Expand-and-contract pattern for breaking changes:

Phase 1 (EXPAND): Support both old and new.
  POST /api/v1/transfers -> old format accepted
  POST /api/v2/transfers -> new format accepted

Phase 2 (MIGRATE): Move all callers to v2.

Phase 3 (CONTRACT): Remove v1.
  Now safe to remove old format.

package com.bank.antipattern;

// WRONG: Shared library with DTO used by 5 services.
// Version bump 1.0 -> 2.0 forces all 5 to redeploy together.
public class SharedTransferDto {
    // private String fromAccountId;
    // Adding a field here forces recompile + redeploy of ALL consumers.
}

// CORRECT: Each service has its own DTO.
// Payment Service has PaymentTransferDto.
// Account Service has AccountTransferDto.
// Small duplication, but no lockstep.

Shared library lockstep symptoms:
- Version bump in shared-lib requires all services to upgrade
- Cannot deploy one service without upgrading shared-lib first
- One library change triggers 5+ pipeline rebuilds

Fix: keep shared libraries tiny, version them,
prefer duplication of a small DTO over coupling.

Verification checklist:
[x] Own repository or clearly separated module
[x] Own CI/CD pipeline triggered only by its own changes
[x] Private database with no shared tables
[x] API changes are additive (no breaking changes)
[x] Kafka schema evolution is additive (with registry)
[x] No shared-library version bump forces coordinated deploy
[x] Has deployed to production independently at least once

package com.bank.antipattern;

// WRONG: Two "services" that always deploy together.
public class DistributedMonolith {
    // Transfer Service calls Limit-Check Service synchronously.
    // They share a database.
    // They always deploy at the same time.
    // Every feature touches both.
    // This is a monolith with network hops.
}

// CORRECT: Merge them back into one service.
public class ProperMonolith {
    // Limit checking is a method inside Transfer Service.
    // One database, one deploy, one transaction.
    // Split only when a separate team needs independent ownership.
}