GopherForgeA WORKBENCH FOR GO
← Course map

GO LEARNING PATH · 9 LESSONS

Architecture: consistency and evolution

Transactions, outbox/inbox, sagas, compatible changes, tenant isolation and observability.

  1. A use case owns its transaction, not its HTTP handler

    Keep the business invariant and transaction boundary in the application service.

    3 min · Worked lesson

  2. Outbox and inbox: close the database–broker gap

    Commit a business change and its publication intent together, then deduplicate delivery.

    3 min · Worked lesson

  3. Sagas: compensate business steps without pretending to roll back time

    Model a distributed workflow as durable states with explicit compensation and recovery.

    3 min · Worked lesson

  4. Evolve APIs, events and schemas across mixed deployments

    Use expand–migrate–contract changes while old and new Go processes coexist.

    3 min · Worked lesson

  5. Tenant isolation belongs in every access path

    Carry a verified tenant identity into storage predicates, cache keys and background jobs.

    3 min · Worked lesson

  6. Observe a Go use case without drowning in cardinality

    Connect structured logs, bounded metrics and traces to an explicit service objective.

    3 min · Worked lesson

  7. gRPC and Protobuf: generated methods still need an operational contract

    Define deadlines, stream ownership, status mapping and compatible message evolution.

    3 min · Worked lesson

  8. Kafka-style consumers: commit only a contiguous completed prefix

    Separate message delivery, durable effects and partition-offset ownership.

    3 min · Worked lesson

  9. Consistency under partitions: explain an operation, not a slogan

    Choose per-operation consistency and failure behavior instead of treating CAP as a product rating.

    3 min · Worked lesson