Should every microservice publish an event for every database change

package com.bank.events;

// WRONG: event that mirrors the database table structure
public class AccountRowChangedEvent {
    private String operationType;  // INSERT, UPDATE, DELETE
    private String accountId;
    private String accountNumber;
    private String internalStatus; // DRAFT, VALIDATING, RISK_CHECKED
    private String customerIdFk;   // internal foreign key
    private String denormBalance;   // denormalized column
    // Exposes every internal column as a public contract!
}

Problems with raw changelog events:
  1. Internal columns (internalStatus, customerIdFk) exposed publicly
  2. Consumers depend on column names you want to rename
  3. Schema migration = breaking change for all consumers
  4. One transfer touches 5 rows = 15 events (noisy)
  5. Intermediate states (DRAFT, VALIDATING) leak internal state machine

Harm 1: Exposure of internals
  Internal staging states (DRAFT, VALIDATING, RISK_CHECKED) visible
  Consumers build logic on states you need to change

Harm 2: Painful schema evolution
  Rename account_number -> acc_num?
  Every consumer breaks, even though this is YOUR internal table
  The freedom to evolve your own data model (a key benefit of
  database-per-service) is gone

Harm 3: Semantic noise
  Consumer receives:
    INSERT account_row (status=DRAFT)
    UPDATE account_row (status=VALIDATING)
    UPDATE account_row (status=RISK_CHECKED)
    UPDATE account_row (status=COMPLETED)
    INSERT ledger_entry
  Must reverse-engineer: "oh, a transfer completed"

Harm 4: Tight coupling
  The whole point of events was loose coupling
  Raw changelog events deliver the opposite

package com.bank.events;

import java.math.BigDecimal;
import java.time.Instant;

// CORRECT: deliberate domain-fact event
public class TransferCompletedEvent {
    private String transferId;      // business identifier
    private String fromAccountId;   // SAV2001
    private String toAccountId;     // SAV2002
    private BigDecimal amount;      // 50000.00
    private String currency;        // INR
    private Instant completedAt;    // when it finished

    // Only curated fields consumers actually need
    // No internal states, no FK columns, no denormalized data
}

package com.bank.transfer;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.math.BigDecimal;

@Service
public class TransferService {

    private final AccountRepository accountRepo;
    private final OutboxRepository outbox;

    public TransferService(AccountRepository accountRepo,
                            OutboxRepository outbox) {
        this.accountRepo = accountRepo;
        this.outbox = outbox;
    }

    @Transactional
    public void transfer(String from, String to, BigDecimal amount) {
        // Business logic touches multiple rows/tables internally
        accountRepo.debit(from, amount);
        accountRepo.credit(to, amount);
        accountRepo.updateStatus(from, "COMPLETED");

        // ONE curated domain-fact event, not N row-change events
        outbox.save(new OutboxEvent(
            "TransferCompleted",
            new TransferCompletedEvent(
                "TXF-" + System.currentTimeMillis(),
                from, to, amount, "INR")
        ));
    }
}

Raw changelog: 5 rows changed = 15 events (noisy, leaky)
Domain facts:  1 business operation = 1 TransferCompleted event (clean)

package com.bank.outbox;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import java.time.Instant;

@Entity
@Table(name = "outbox_events")
public class OutboxEvent {

    @Id
    private String eventId;
    private String eventType;    // "TransferCompleted"
    private String payload;       // JSON of the curated event
    private Instant createdAt;
    private boolean published;

    // CDC reads from this table, not from business tables
    // Publisher marks published=true after sending to Kafka
}

Outbox pattern flow:
  1. Business logic writes to business tables
  2. In the SAME transaction, writes curated event to outbox table
  3. CDC (Debezium) reads outbox table and publishes to Kafka
  4. CDC publishes YOUR chosen events, not raw table mutations
  5. Internal schema changes do not affect the outbox contract

Event versioning rules:
  Safe changes (backward compatible):
    - Add a new optional field
    - Add a new event type
    - Add a default value to an existing field

  Breaking changes (require new version):
    - Remove a field
    - Rename a field
    - Change a field's type
    - Change the meaning of a field

  Schema Registry enforces compatibility:
    - BACKWARD: new schema can read old data
    - FORWARD: old schema can read new data
    - FULL: both directions

package com.bank.events;

// Decision framework
public class EventDecision {
    /*
     * Publish as event:
     *   TransferCompleted  -> notification service needs it
     *   AccountFrozen      -> fraud service needs it
     *   LoanApproved       -> document service needs it
     *
     * Keep private:
     *   Transfer status: DRAFT -> VALIDATING  (internal state)
     *   Ledger entry created  (implementation detail)
     *   Balance column updated  (persistence internals)
     *   Risk score recalculated  (intermediate computation)
     */
}

WRONG: CDC on business tables
  Debezium watches accounts table -> every UPDATE becomes an event
  Consumer depends on column names -> schema evolution blocked

CORRECT: CDC on outbox table
  Business writes curated event to outbox table
  Debezium watches outbox -> publishes YOUR chosen events
  Internal schema changes do not affect consumers