Architecture & Patterns Glossary

A reference for architecture patterns and design concepts used in Go service development.

Term	Definition
Bulkhead Pattern	Isolates failure domains by capping concurrent resource consumption per dependency, preventing one slow service from exhausting goroutines across the entire application.
Circuit Breaker	Monitors calls to external services and stops sending requests when failure rates exceed a threshold, giving the downstream system time to recover and preventing cascade failures.
Clean Architecture	Four-layer design (entities, use cases, interfaces, infrastructure) where all dependencies point inward toward business rules, enabling full replacement of database or framework without touching domain logic.
CQRS	Separates the write model (commands applied to aggregates) from the read model (denormalized projections optimized for queries), decoupling read and write scaling requirements.
Dependency Injection	Supplies a component with its dependencies from the outside rather than creating them internally — making Go services testable, flexible, and architecturally clean.
Domain-Driven Design	A software development approach that centers code structure on the business domain using building blocks — entities, value objects, aggregates, and domain events — to make domain rules explicit in code.
Event-Driven Architecture	Services communicate by producing and consuming events rather than making direct synchronous calls, enabling async processing, loose coupling, and independent scaling.
Hexagonal Architecture	Organizes services into concentric layers (domain, port, service, adapter) where inner layers never import outer layers, keeping business logic independent of HTTP, database, and external systems.
Idempotency	An operation that produces the same result regardless of how many times it’s executed — essential for safe retries in payment processing, webhook handling, and distributed workflows.
JWT Authentication	Stateless identity verification using cryptographically signed tokens, enabling Go APIs to authenticate requests without a database lookup on every call.
Layered Architecture	The most common Go service pattern — handler, service, and repository layers with strict downward dependency direction, suited for standard CRUD APIs and straightforward business logic.
OpenTelemetry	The open standard for distributed tracing, metrics, and logs in Go services — instrument once, export to any observability backend without vendor lock-in.
Outbox Pattern	Guarantees reliable event publishing by writing events to an outbox table in the same database transaction as the business operation, then relaying them asynchronously.
Ports and Adapters	The original name for hexagonal architecture — ports are domain-owned interfaces defining what the application needs; adapters are infrastructure implementations that plug into those ports.
Rate Limiting	Controls request throughput per client identity using token bucket or leaky bucket algorithms — protecting Go APIs from abuse and ensuring fair resource allocation.
Repository Pattern	Abstracts data access behind a domain-oriented interface, decoupling business logic from storage technology and enabling in-memory test doubles without a running database.
Saga Pattern	Manages distributed transactions across microservices using a sequence of local transactions with compensating actions — maintaining data consistency without two-phase commit.
Service Mesh	An infrastructure layer that handles service-to-service communication (mTLS, retries, observability) via sidecar proxies, without requiring changes to Go application code.