Design Patterns (Backend-Relevant)

A design pattern is a named, reusable solution to a recurring design problem, described by intent, structure and trade-offs rather than concrete code. It gives teams a shared vocabulary ("wrap it in a decorator") and captures known consequences.

• GoF patterns fall into creational, structural and behavioral groups.
• In backend work the value is recognizing the pattern inside frameworks (Spring, JDK) and picking one deliberately instead of by habit.

Make the constructor private and expose one instance created safely. The common options are eager initialization, double-checked locking with a volatile field, the initialization-on-demand holder, or a single-element enum.

public final class Config {
    private static volatile Config instance;
    private Config() {}
    public static Config get() {
        Config c = instance;
        if (c == null) {
            synchronized (Config.class) {
                c = instance;
                if (c == null) instance = c = new Config();
            }
        }
        return c;
    }
}

• Without volatile, another thread may see a non-null but partially constructed object because of instruction reordering.
• Eager static final initialization is simplest when construction is cheap.

A private static nested class holds the instance in a static final field. The JVM initializes the holder class lazily, on first access of getInstance(), and class initialization is guaranteed thread-safe by the JLS.

public final class Registry {
    private Registry() {}
    private static class Holder { static final Registry INSTANCE = new Registry(); }
    public static Registry getInstance() { return Holder.INSTANCE; }
}

• No explicit locking and no volatile, yet lazy.
• Cannot take constructor arguments and cannot recover from an exception in the constructor (the class becomes unusable with NoClassDefFoundError).

enum Singleton { INSTANCE; } gets thread-safe lazy-on-class-load creation, built-in serialization safety, and protection against reflection instantiation, all from the language.

• Normal singletons break on deserialization unless readResolve() returns the instance.
• Constructor.newInstance on an enum throws IllegalArgumentException.
• Limitations: cannot extend another class (can implement interfaces) and is created at enum class load, not lazily on demand.

Static singletons are hidden global state: hard to mock, order-dependent in tests, and tightly coupled to callers. Spring replaces them with singleton-scoped beans, where the container manages one instance per ApplicationContext and injects it.

• Spring's "singleton" means one instance per container per bean definition, not per JVM or per class.
• The bean must be stateless or thread-safe because many request threads share it.

Define a method that creates an object, letting callers depend on an interface while subclasses or the factory decide the concrete type. It centralizes creation logic and hides constructors.

interface Notifier { void send(String msg); }
final class NotifierFactory {
    static Notifier of(String channel) {
        return switch (channel) {
            case "email" -> new EmailNotifier();
            case "sms"   -> new SmsNotifier();
            default -> throw new IllegalArgumentException(channel);
        };
    }
}

• JDK examples: List.of, Calendar.getInstance, NumberFormat.getInstance, Optional.of.
• Static factory methods also give names, caching and subtype return, unlike constructors.

Factory Method creates one product; Abstract Factory creates a family of related products behind one interface so they stay consistent.

• Example: a DatabaseDialectFactory returning matching QueryBuilder, TypeMapper and Migrator for PostgreSQL or MySQL.
• JDK example: DocumentBuilderFactory, and JDBC Connection creating Statement, PreparedStatement for one driver.
• Adding a new product type forces changes in every factory; adding a new family is easy.

Use Builder when an object has many optional parameters or must be immutable but validated at construction. It avoids telescoping constructors and unreadable positional arguments.

public final class HttpCall {
    private final String url; private final int timeoutMs;
    private HttpCall(Builder b) { url = b.url; timeoutMs = b.timeoutMs; }
    public static Builder builder(String url) { return new Builder(url); }
    public static final class Builder {
        private final String url; private int timeoutMs = 3000;
        private Builder(String url) { this.url = url; }
        public Builder timeoutMs(int t) { timeoutMs = t; return this; }
        public HttpCall build() { return new HttpCall(this); }
    }
}

• Validate invariants in build().
• JDK examples: StringBuilder, HttpClient.newBuilder(), Stream.Builder; Lombok's @Builder generates one.

Create new objects by copying an existing instance instead of constructing from scratch. It is useful when construction is expensive or the concrete type is unknown at the call site.

• Cloneable/Object.clone() does a shallow field copy and is considered flawed: no constructor call, checked exception, and a marker interface with no methods.
• Prefer copy constructors or copy factories, or deep copy via serialization or mapping libraries.
• Spring's prototype scope returns a fresh bean instance per injection or getBean call.

Adapter converts one interface into another that clients expect, so incompatible classes can collaborate without changing either.

• Typical backend use: wrapping a third-party payment SDK behind your own PaymentGateway interface.
• JDK: Arrays.asList (array to List), InputStreamReader (bytes to chars), Collections.enumeration.
• Spring: HandlerAdapter lets DispatcherServlet invoke different handler types uniformly; HttpMessageConverter adapts bodies.

Decorator wraps an object implementing the same interface to add behavior before or after delegating, composable at runtime without subclass explosion.

interface PriceService { double price(String sku); }
class CachingPriceService implements PriceService {
    private final PriceService delegate; private final Map<String, Double> cache = new ConcurrentHashMap<>();
    CachingPriceService(PriceService d) { delegate = d; }
    public double price(String sku) { return cache.computeIfAbsent(sku, delegate::price); }
}

• JDK: BufferedInputStream, Collections.unmodifiableList, Collections.synchronizedMap.
• Spring: HttpServletRequestWrapper, BeanPostProcessor wrapping beans.

A proxy is a stand-in with the same interface that controls access to the real object. Kinds: virtual (lazy loading), protection (authorization), remote (RPC stubs), and smart (caching, logging, transactions).

• Hibernate lazy entities and getReference() return virtual proxies.
• Spring AOP uses proxies to apply @Transactional, @Cacheable, @Async, @Retryable.
• Feign/Retrofit clients are remote proxies generated from interfaces.

JDK proxies (java.lang.reflect.Proxy) implement the target's interfaces and route calls through an InvocationHandler. CGLIB (repackaged in Spring, using ByteBuddy-like subclass generation) creates a subclass of the target class and overrides its methods.

• Spring Boot 2+ defaults to CGLIB (spring.aop.proxy-target-class=true), so interfaces are not required.
• CGLIB cannot proxy final classes or final/private methods; they run unadvised on the proxy instance.
• JDK proxies can only expose interface methods; casting to the concrete class fails.

Runnable r = (Runnable) Proxy.newProxyInstance(
    Runnable.class.getClassLoader(), new Class<?>[]{Runnable.class},
    (proxy, m, args) -> { System.out.println("before"); return null; });

Facade provides a single simplified interface to a complex subsystem, reducing coupling between clients and many internal classes.

• Backend example: an OrderFacade.placeOrder() orchestrating inventory, payment, and shipping services so the controller makes one call.
• JDK/Spring: JdbcTemplate, RestTemplate/RestClient, and SLF4J are facades over lower-level APIs.
• Risk: a facade that accumulates business logic becomes a god class.

Composite lets you treat individual objects and groups of objects uniformly through a common interface, forming tree structures.

interface Rule { boolean test(Order o); }
record AllOf(List<Rule> rules) implements Rule {
    public boolean test(Order o) { return rules.stream().allMatch(r -> r.test(o)); }
}

• Backend uses: menu/permission trees, nested validation rules, Specification and/or, composite health indicators, Predicate.and().
• Spring: CompositeHealthContributor, DelegatingPasswordEncoder, CompositeCacheManager.

Strategy encapsulates interchangeable algorithms behind an interface so the algorithm can be selected at runtime without conditionals in the client.

• Spring examples: PasswordEncoder, HandlerMapping, ViewResolver, TransactionManager, CacheResolver, AuthenticationProvider, RetryPolicy.
• JDK: Comparator, ExecutorService rejection policies.
• In modern Java a strategy is often just a lambda or method reference.

Observer defines a one-to-many dependency: when a subject changes state, registered observers are notified automatically, decoupling publisher from subscribers.

• JDK: java.util.Observable/Observer are deprecated since Java 9; use PropertyChangeListener, Flow (reactive streams) or your own listener interfaces.
• Spring: ApplicationEventPublisher plus @EventListener; @TransactionalEventListener fires after commit.
• Listeners are synchronous on the publishing thread by default, so a slow or failing listener affects the publisher unless @Async is used.

A base class defines the skeleton of an algorithm in a final method and defers certain steps to subclasses through abstract or hook methods.

abstract class ReportJob {
    public final void run() { var data = load(); var out = format(data); publish(out); }
    protected abstract List<String> load();
    protected abstract String format(List<String> d);
    protected void publish(String s) { System.out.println(s); }
}

• Spring examples: JdbcTemplate, TransactionTemplate, AbstractController, OncePerRequestFilter.doFilterInternal.
• Callback-based variants (JdbcTemplate.query(sql, rowMapper)) replace inheritance with lambdas.

A request passes along a chain of handlers; each handler processes it, modifies it, or passes it on, so the sender does not know which handler acts.

• Servlet Filter chain and Spring Security's SecurityFilterChain; HandlerInterceptor chain.
• Logging frameworks: appenders and log levels; Netty ChannelPipeline.
• Each handler decides whether to continue (chain.doFilter(req, res)); forgetting the call silently stops the request.

Command wraps a request as an object with an execute method (and possibly undo), so requests can be queued, logged, retried, scheduled or sent across process boundaries.

• Runnable/Callable submitted to an ExecutorService are commands.
• Backend: job queues, CQRS command objects (CreateOrderCommand), Spring Batch steps, event-sourced commands.
• Serializable commands enable audit logs and replay.

State lets an object alter its behavior when its internal state changes by delegating to a state object, replacing large if/switch blocks on a status field.

enum OrderState {
    NEW { OrderState next() { return PAID; } },
    PAID { OrderState next() { return SHIPPED; } },
    SHIPPED { OrderState next() { throw new IllegalStateException(); } };
    abstract OrderState next();
}

• Enums with behavior are the lightweight Java form; Spring Statemachine is a library for complex flows.
• Persist only the state name; reconstruct behavior from it.

Visitor separates an operation from the object structure via double dispatch: elements expose accept(visitor) and call visitor.visit(this). It makes adding operations easy but adding element types hard.

• Java 17+ sealed interfaces with pattern matching switch give exhaustive dispatch without boilerplate.
• JDK examples: Files.walkFileTree with FileVisitor, ElementVisitor in annotation processing.

sealed interface Expr permits Num, Add {}
record Num(int v) implements Expr {}
record Add(Expr l, Expr r) implements Expr {}
static int eval(Expr e) {
    return switch (e) { case Num n -> n.v(); case Add a -> eval(a.l()) + eval(a.r()); };
}

IoC means a framework controls object creation and wiring instead of your code. Dependency Injection is the technique: collaborators are supplied to an object rather than looked up or constructed by it.

• Types: constructor, setter, field injection; constructor injection is preferred for immutability, required dependencies and easy unit testing.
• Benefits: loose coupling to interfaces, easy substitution with mocks, central lifecycle management.
• Spring's container (ApplicationContext) resolves types, creates beans and applies proxies.

Constructor-injected cycles fail with BeanCurrentlyInCreationException. Setter/field cycles for singletons used to be resolved through early references (three-level cache), but Spring Boot 2.6+ prohibits circular references by default.

• A cycle signals a design problem; break it by extracting a third component, using events, or @Lazy on one injection point.
• spring.main.allow-circular-references=true re-enables the old behavior; use it only as a stopgap.

singleton (default, one per container), prototype (new per request for the bean), and web scopes request, session, application, websocket.

• Singleton scope is the container-managed Singleton; prototype is Prototype.
• Injecting a prototype into a singleton yields one instance created at injection time; use ObjectProvider, @Lookup or a scoped proxy for a fresh one per use.

BeanFactory/ApplicationContext are factories for beans. FactoryBean<T> customizes creation of a bean, and @Bean methods are factory methods on configuration classes.

• FactoryBean examples: ProxyFactoryBean, LocalContainerEntityManagerFactoryBean.
• Injecting &myFactoryBean returns the factory itself, while myFactoryBean returns the product.
• ObjectProvider<T> and Supplier beans offer lazy, repeatable creation.

• Template Method: JdbcTemplate, RestTemplate, TransactionTemplate.
• Proxy: AOP for @Transactional, @Cacheable, @Async, Spring Data repositories.
• Observer: ApplicationEvent and @EventListener.
• Strategy: PasswordEncoder, HandlerMapping, ResourceLoader.
• Adapter: HandlerAdapter, HttpMessageConverter, JpaVendorAdapter.
• Singleton: default bean scope.
• Decorator: BeanPostProcessor wrappers, request wrappers.
• Chain of Responsibility: security filter chain, interceptors.
• Front Controller: DispatcherServlet.

Proxy-based AOP intercepts calls entering through the proxy object. A call to this.otherMethod() inside the target goes straight to the real object, so @Transactional, @Cacheable and @Async on the callee are skipped.

• Fixes: move the method to another bean, inject the bean into itself via ObjectProvider/@Lazy, use AopContext.currentProxy(), or switch to AspectJ weaving.
• Same applies to private, final and (for JDK proxies) non-interface methods.

A Repository gives collection-like access to aggregate roots in domain terms (orders.findById, orders.add), hiding persistence. A DAO is a lower-level table-oriented gateway exposing CRUD operations on a data source.

• Repository comes from DDD: one per aggregate root, returns domain objects, speaks the ubiquitous language.
• DAO maps closely to tables or entities and is a data-access abstraction.
• Spring Data JpaRepository is a repository abstraction generated via proxies; a plain EntityManager wrapper is closer to DAO.

A DTO (Data Transfer Object) is a plain data carrier shaped for a boundary such as a REST response. Separating it from the JPA entity decouples the API contract from the database schema and avoids leaking lazy associations, internal fields and bidirectional cycles.

• Use records (Java 16+) for immutable DTOs.
• Map with MapStruct or manual mappers; Spring Data supports interface/class projections to load only needed columns.
• Return DTOs from controllers to avoid LazyInitializationException and accidental over-exposure (for example password hashes).

Unit of Work tracks changes to objects during a business transaction and writes them together at commit. The JPA persistence context does this: managed entities are tracked and dirty ones are flushed as SQL on commit or flush.

• Along with an identity map: within one persistence context the same row yields the same instance.
• @Transactional defines the unit's boundary; EntityManager.flush() forces writes early.

Command Query Responsibility Segregation separates the write model (commands that change state) from the read model (queries returning data), allowing each to be optimized and scaled independently.

• Simple form: separate command and query services sharing one database.
• Advanced form: separate stores, with read models (denormalized tables, Elasticsearch, Redis) updated from events asynchronously.
• Cost: eventual consistency between sides, more code, and duplicated models.

Event Sourcing stores state as an append-only sequence of domain events; current state is derived by replaying events (optionally from snapshots). Projections build read models for the query side of CQRS.

• Gives a complete audit trail and temporal queries.
• Challenges: event schema evolution (upcasting), replay time, GDPR deletion, and eventual consistency.

Outbox solves the dual-write problem: instead of updating the database and publishing to a broker separately, write the business change and an outbox row in one local transaction; a relay later publishes outbox rows to the broker.

• Relay options: polling publisher, or CDC (Debezium) tailing the DB log.
• Delivery is at-least-once, so consumers must be idempotent.
• Table typically has id, aggregate id, type, payload, created_at, published flag.

A saga is a sequence of local transactions across services, where each step has a compensating action to undo it if a later step fails. It replaces distributed 2PC with eventual consistency.

• Choreography: services react to each other's events; simple but hard to follow with many steps.
• Orchestration: a central coordinator issues commands and tracks state; clearer, but a coordinator to maintain.
• Compensations are semantic undo (refund, release stock), not rollbacks, and must be idempotent and retriable.

A circuit breaker wraps calls to a remote dependency and tracks failures. States: CLOSED (calls flow), OPEN (calls fail fast), HALF_OPEN (a few trial calls decide whether to close again).

• Opens when failure or slow-call rate crosses a threshold in a sliding window; waits waitDurationInOpenState before half-open.
• Libraries: Resilience4j (@CircuitBreaker), Spring Cloud CircuitBreaker; Hystrix is retired.
• Combine with timeouts, retries with backoff, bulkheads and fallbacks.

Bulkhead isolates resources per dependency (separate thread pools or semaphores) so one slow service cannot exhaust all threads. Retry repeats transient failures, ideally with exponential backoff and jitter.

• Order of decorators in Resilience4j aspects: Retry( CircuitBreaker( RateLimiter( TimeLimiter( Bulkhead( fn ))))).
• Retry only idempotent operations, or use idempotency keys.
• Retry storms multiply load on a struggling service; cap attempts and add jitter.

An operation is idempotent if repeating it has the same effect as doing it once. GET, PUT, DELETE are idempotent by HTTP semantics; POST is not, so APIs accept an Idempotency-Key header.

• Store key plus request fingerprint and response in a table with a unique constraint; on replay return the stored response.
• Use INSERT ... ON CONFLICT DO NOTHING or unique index to make the check atomic.
• Expire keys after a retention window.

A Specification encapsulates a business rule as an object that answers isSatisfiedBy(candidate) and can be combined with and/or/not. It keeps query and validation criteria reusable.

• Spring Data JPA Specification<T> builds dynamic Criteria predicates and composes with and()/or().
• Useful for search filters with optional parameters.

A Null Object implements the interface with neutral do-nothing behavior so callers need not check for null.

• Examples: Collections.emptyList(), Optional.empty(), NoOpCacheManager, a NoopMetrics implementation.
• Use Optional for return types that may be absent; use Null Object where a collaborator is optional.
• Avoid when silent no-op hides an actual error.

Many behavioral patterns shrink to functions when the participant has one method.

• Strategy: Function/Comparator lambda instead of a class hierarchy.
• Command: Runnable/Callable/Supplier.
• Template Method: pass step functions or use callbacks (JdbcTemplate row mappers).
• Observer: Consumer listeners or Flow.Subscriber.
• Decorator: function composition (Function.andThen, Predicate.and).
• Visitor: sealed types plus pattern-matching switch.
• Builder: records with with-style copy methods.

Keep classes when behavior needs state, names, several methods, or independent testing and discoverability.

• God object: one class doing everything.
• Anemic domain model: entities with only getters/setters and all logic in services.
• Singleton abuse: global mutable state.
• Service Locator: hidden dependencies via static lookup.
• Golden hammer: applying one pattern everywhere.
• Spaghetti code and lava flow: tangled or dead code left in place.
• Premature abstraction: interfaces with single implementations and factories for trivial objects.
• Distributed monolith: microservices that must deploy together.
• Shared database across services.

• S, Single Responsibility: separate order pricing from order persistence.
• O, Open/Closed: add a new payment method by adding a class, not editing a switch.
• L, Liskov Substitution: subclasses must honor the base contract (a read-only list that throws on add violates it).
• I, Interface Segregation: small role interfaces instead of a fat Repository.
• D, Dependency Inversion: services depend on PaymentGateway, not on StripeClient.

Spring creates a JDK proxy for each repository interface at startup. Calls route to SimpleJpaRepository for CRUD methods and to query lookup strategies for derived names and @Query methods, all wrapped in transactional interceptors.

• Method names like findByEmailAndActiveTrue are parsed into a PartTree and converted to criteria queries.
• Default repository methods are @Transactional(readOnly = true) for reads and @Transactional for writes.

Mediator centralizes communication between components so they interact with the mediator instead of each other, reducing many-to-many coupling.

• Examples: DispatcherServlet mediating controllers and views, ApplicationEventPublisher as an event bus, in-app command buses.
• Observer defines a subject-to-many direction; Mediator coordinates two-way interactions and may contain routing logic.

Iterator provides sequential access to a collection's elements without exposing its representation. In Java: Iterator<E>, Iterable for the for-each loop, and Stream for pipelines.

• Custom collections implement Iterable<T> and return an Iterator with hasNext/next.
• Most JDK iterators are fail-fast and throw ConcurrentModificationException on structural changes outside the iterator.

Memento captures an object's internal state externally so it can be restored later without breaking encapsulation. In backends this appears as aggregate snapshots in event sourcing, saga state persistence and undo/audit versions.

• A snapshot is stored every N events to bound replay time.
• Keep mementos immutable; the originator creates and restores them, other classes treat them as opaque.

A single handler receives all requests and dispatches them to appropriate handlers, centralizing cross-cutting concerns such as security and routing. Spring MVC's DispatcherServlet is the canonical implementation.

• Flow: HandlerMapping finds the handler, HandlerAdapter invokes it, HttpMessageConverter or ViewResolver renders the result, and exception resolvers handle errors.
• Interceptors and filters wrap this flow.

Flyweight shares immutable intrinsic state among many objects to save memory, keeping extrinsic state outside.

• JDK: the Integer.valueOf cache for -128..127, the String pool, Boolean.TRUE, enum constants.
• Backend: caching immutable reference data such as currency or country objects instead of loading them per request.

An Anti-Corruption Layer translates between your domain model and an external or legacy model, so the foreign concepts and naming never leak in. It combines Adapter, Facade and mappers.

• Implement as a CustomerGateway interface in the domain with an implementation that calls the legacy API and converts its DTOs.
• Isolates changes: a vendor API version bump touches only the ACL.

• Factory: choose which type to create based on input, hiding the constructor.
• Builder: assemble one complex object step by step with many optional parts.
• Prototype: copy an existing configured instance.
• Abstract Factory: create consistent families of objects.
• Singleton: guarantee exactly one instance.

instance = new Config() involves allocate, construct, assign the reference. Without a happens-before edge the JIT or CPU may publish the reference before construction finishes, so another thread sees a half-built object. volatile forbids that reordering.

• Immutable objects with only final fields are safely published even through a data race (final field semantics).
• Other safe publication: static initializers, synchronized, volatile, or concurrent collections.

Almost certainly double-checked locking without volatile: a thread sees a non-null reference before the constructor's writes are visible. Mark the field volatile, or switch to the holder idiom or an eager static final.

• It reproduces rarely and only on multi-core hardware or after JIT optimization, which is why it passes tests.

Singleton beans are shared by every request thread, so a mutable field is shared state. Remove the field and pass the user as a method parameter or read it from SecurityContextHolder; for per-request state use a request-scoped bean with a scoped proxy.

• ThreadLocal works but must be cleared in finally on pooled threads.

Strategy with a registry. Define PaymentProvider with String id() and charge(...), implement per provider as beans, and inject List<PaymentProvider> or Map<String, PaymentProvider> into a router that picks by id.

@Service
class PaymentRouter {
    private final Map<String, PaymentProvider> byId;
    PaymentRouter(List<PaymentProvider> all) {
        byId = all.stream().collect(Collectors.toMap(PaymentProvider::id, p -> p));
    }
    PaymentProvider forId(String id) {
        var p = byId.get(id);
        if (p == null) throw new IllegalArgumentException("Unknown provider " + id);
        return p;
    }
}

Adding a provider means adding a bean; no existing code changes.

Introduce a Builder (or a record with a compact constructor plus a builder) with named setters, defaults for optional fields, and validation in build(). Group related params into value objects (DateRange, Paging) first; fewer parameters often removes the need.

Decorators (one wrapper per concern implementing PriceService) or Spring AOP aspects for cross-cutting concerns applied declaratively. Use explicit decorators when behavior is specific to one interface and order must be visible; use aspects when the same concern applies to many beans.

• Order matters: caching outside audit logs hits only on misses; metrics outside caching includes cache hits.
• Spring: @Order on aspects or @Primary on the outermost decorator.

Self-invocation bypasses the Spring proxy, so the interceptor never runs. Extract the method to a separate bean, or inject the proxy via @Lazy self-reference, or use TransactionTemplate programmatically.

Injected references are proxies; this is the raw target. proxy == this is false and proxy.equals(this) depends on implementation. Avoid identity comparisons on beans, and compare by id or business key.

• AopProxyUtils.getSingletonTarget or AopUtils.isAopProxy reveal proxies.
• Hibernate entity proxies have the same issue: use Hibernate.unproxy or compare by id, and avoid getClass() in equals.

Typical causes: self-invocation, missing @EnableAsync, calling a private/final method, or the bean being created outside Spring (new). @Async is applied via a proxy that submits the call to a TaskExecutor.

• Provide a bounded executor bean; the default SimpleAsyncTaskExecutor creates a thread per task (Spring Boot auto-configures a pooled applicationTaskExecutor).

Layer protections: client timeouts (connect and read), a circuit breaker to fail fast, a bulkhead to cap concurrent calls to that dependency, and a fallback (cached or degraded response).

resilience4j:
  circuitbreaker:
    instances:
      inventory:
        slidingWindowSize: 20
        failureRateThreshold: 50
        waitDurationInOpenState: 10s
  bulkhead:
    instances:
      inventory:
        maxConcurrentCalls: 10

Use the Transactional Outbox: insert the order and an outbox row in the same DB transaction; a poller or Debezium CDC publishes rows to Kafka and marks them sent. Consumers dedupe by event id.

CREATE TABLE outbox (
  id UUID PRIMARY KEY, aggregate_id VARCHAR(64) NOT NULL,
  type VARCHAR(64) NOT NULL, payload JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT now(), published_at TIMESTAMP NULL);

Use an orchestrated saga: Order service starts, reserves inventory, charges payment; on failure it issues compensations (release stock, cancel order). Orchestration is preferable with 3+ steps because the flow and failure paths are explicit and observable.

• Each step is a local transaction plus outbox event; every command and compensation is idempotent.
• Model intermediate states (PENDING, RESERVED, PAID, CANCELLED) to expose in-flight status.
• Avoid 2PC/XA: low availability and poor broker/NoSQL support.

Require an Idempotency-Key header. In one transaction insert the key (unique constraint) with status IN_PROGRESS, execute, then store the response. Replays with a completed key return the stored response; concurrent duplicates get 409 or wait.

try {
    keys.insert(key, requestHash);        // unique(key)
} catch (DuplicateKeyException e) {
    return keys.find(key).responseOrConflict(requestHash);
}

Also pass the key to the payment provider, which supports its own idempotency.

Assume at-least-once delivery and make the handler idempotent: store processed message ids in the same transaction as the business change (unique constraint), or design updates as upserts or absolute-state writes rather than increments.

Return DTOs (records) built in the service layer inside the transaction, or use projections to select only needed fields. Never expose entities across the API boundary.

record UserView(Long id, String email) {}
interface UserRepo extends JpaRepository<User, Long> {
    List<UserView> findByActiveTrue();
}

CQRS with a denormalized read model: keep writes on the normalized transactional tables, and project events (via outbox/CDC) into a read store such as a materialized view, replica, Elasticsearch or Redis. Start with read replicas or materialized views before full separation.

• Accept eventual consistency and communicate it in the UX (for example "updating...").
• Rebuildable projections let you reshape read models later.

Template Method for the fixed flow with channel-specific hooks, or better, composition: a NotificationService with the flow, and a ChannelSender strategy per channel exposing send and retryPolicy(). Prefer composition because channels vary in more than one dimension.

Composite plus Specification: a Rule interface with AndRule, OrRule, NotRule composites and leaf rules. Rules are data-driven (loaded from config), testable individually, and evaluated recursively. With Predicate<T> you get and/or/negate for free.

Introduce an anti-corruption layer: a domain-owned interface (ShippingGateway) with an adapter in infrastructure that calls the SOAP client and maps vendor DTOs to domain types. Business code never imports vendor classes.

Replace conditionals with State: an enum or sealed state types that own allowed transitions and behavior. The aggregate holds the state and delegates submit(), approve(); illegal transitions throw a domain exception.

• Persist as @Enumerated(EnumType.STRING), not ordinal.
• For complex flows with guards and events, consider Spring Statemachine.

Command: model each action as a command object with execute() and undo() (or a compensating command), persist command records with actor, time and payload, and store inverse data needed to undo.

Chain of Responsibility via servlet filters or a Spring Security SecurityFilterChain. Each filter does its work and calls chain.doFilter. Control order using FilterRegistrationBean.setOrder or @Order.

Publish an OrderPaidEvent via ApplicationEventPublisher; each component has an @EventListener (or @TransactionalEventListener(AFTER_COMMIT)). The order service no longer knows the subscribers.

• For cross-service delivery use a broker (outbox plus Kafka).
• Use @Async for slow listeners and handle their errors.

Strategy for tenant resolution (header, subdomain, JWT claim) plus a routing data source: AbstractRoutingDataSource looks up the tenant key (stored in a ThreadLocal/request scope) and returns the matching DataSource, a Factory/registry creating pools lazily.

• Clear the tenant context in finally; otherwise pooled threads leak the previous tenant.
• Bound the number of pools (Hikari per tenant is costly); prefer schema or discriminator column at scale.

The singleton is created once, so its injection point is resolved once. Inject ObjectProvider<MyPrototype> and call getObject() per use, or use @Lookup, or a scoped proxy.

Template Method/callback: JdbcTemplate acquires and releases connections, statements and result sets and translates exceptions; you only supply SQL and a RowMapper. Plain JDBC alternative is try-with-resources.

List<String> names = jdbc.query("select name from users where active = ?",
    (rs, i) -> rs.getString("name"), true);

Single-implementation interfaces by habit add navigation overhead without benefit. Introduce an interface when you need a seam: multiple implementations, a boundary (ports and adapters), or test doubles that cannot be done with a mock of the class.

• Mockito can mock classes, so testing alone no longer justifies interfaces.
• Keep interfaces at module boundaries and for strategies.

Possible reasons: multiple ApplicationContexts (parent/child, test contexts), the same class loaded by different class loaders (app servers, plugins), new Foo() bypassing the container, or a prototype scope mistake. A classic static singleton is per class loader; a Spring singleton is per context.

Refactor: extract the shared logic into a third bean, move one dependency to an event, or invert the dependency. Quick fix: @Lazy on one injection point. Last resort: spring.main.allow-circular-references=true.

Use orchestration for 6 steps: a single owner holds the state machine, timeouts and compensations, and operators can see where each instance is stuck. Choreography with 6 services creates implicit cyclic coupling and hidden flow.

• Use an engine such as Temporal, Camunda or a hand-rolled persistent state machine.
• Choreography remains good for 2 to 3 loosely related reactions.

Model nodes as a sealed interface with records and write operations as switch pattern-matching functions. The compiler checks exhaustiveness: adding a node type breaks every non-exhaustive switch at compile time, which is exactly the visitor's safety, with less boilerplate.

Retries with exponential backoff, jitter and a small attempt cap, wrapped by a circuit breaker so retries stop when the partner is clearly down, plus timeouts and a retry budget. Retry only on transient errors (5xx, timeouts, 429 with Retry-After), not 4xx.

Caching decorator/proxy: @Cacheable("catalog") on the service method (Spring cache abstraction) with Caffeine or Redis, and @CacheEvict on updates. Set TTL and size bounds.

Virtual proxy: a lightweight proxy holds the id and loads the real object on first method call. JPA does this with @ManyToOne(fetch = LAZY) and getReference(); in plain code use a Supplier memoized with Lazy-style holder.

API Gateway/Facade (or Backend-for-Frontend) that aggregates the calls and exposes one coarse endpoint. Make downstream calls in parallel (CompletableFuture or virtual threads) with timeouts and partial-response fallbacks.

If the builder passes its mutable list reference to the object, later builder or caller mutations change the "immutable" object. Copy defensively with List.copyOf(list) in the constructor, which also rejects nulls.

Hold an immutable Config in an AtomicReference<Config> (or a volatile field). A reloader builds a new instance and swaps it atomically; readers get a consistent snapshot lock-free. This is copy-on-write with a Singleton accessor.

Specification (Spring Data JpaSpecificationExecutor) or Querydsl predicates: build reusable filter fragments and combine at runtime. Return a Page<DTO> using a projection.

Specification<Order> spec = Specification.where(statusIs(PAID))
    .and(createdAfter(from)).and(customerIs(id));
orders.findAll(spec, pageable);

Use @TransactionalEventListener(phase = AFTER_COMMIT) so the listener runs only after a successful commit. For guaranteed delivery use the outbox, since a crash after commit still loses an in-memory event.

SimpleDateFormat is mutable and not thread-safe; sharing it in a singleton corrupts its internal calendar. Use java.time.format.DateTimeFormatter, which is immutable and thread-safe, and can safely be a static constant.

Strategy plus discovery: Exporter interface; formats register via ServiceLoader (META-INF/services) in plain Java, or as Spring beans collected by List<Exporter>. The router selects by supports(format).

Do not serialize entities. Map to DTOs that contain only the necessary fields and ids of related entities. Annotations like @JsonManagedReference/@JsonBackReference or @JsonIgnore are patches that couple entities to the API.

Ensure single execution via a leader/lock: ShedLock (DB or Redis lock per job name), or run jobs in one dedicated worker or use a queue so each unit is claimed once (SELECT ... FOR UPDATE SKIP LOCKED). Also make sending idempotent so duplicates are harmless.

Replace conditional with polymorphism: move each branch into an implementation of one interface, with a factory or registry to select it. Do it incrementally with tests, starting with the most duplicated switch.

Classic Observer pushes without regard for consumer speed. Reactive Streams (java.util.concurrent.Flow, Reactor) adds backpressure: the subscriber requests n items through Subscription.request(n) and the publisher never sends more.

Decorator. Closing the outermost stream closes the wrapped ones, so use try-with-resources on the outermost (or all) streams. Order matters: buffering outside decompression reads decompressed bytes in larger chunks.

A DiscountRule interface with apply(Cart, Price) returning a new price, held in an ordered list (chain/pipeline) sorted by @Order or priority. Each rule is a small, stateless bean; the engine folds the price through the list. Stop rules (exclusive discounts) can short-circuit.

Cache-aside means read: check cache then DB and populate; write: update DB then invalidate cache. Staleness arises from invalidating before the DB commit (a reader refills the old value), failed invalidations, or long TTLs. Invalidate after commit, set TTLs as a safety net, and use versioned keys or CDC-based invalidation for strictness.

Ports are interfaces owned by the domain (inbound: use cases; outbound: OrderRepository, PaymentGateway). Adapters implement them (REST controller, JPA repository, Kafka publisher). Dependencies point inward so domain code imports no framework.

• Uses Adapter, Repository, Strategy and Dependency Inversion together.
• Pays off in long-lived, complex domains; simple CRUD services rarely need it.

Use optimistic locking (@Version), catch OptimisticLockingFailureException, reload and retry a bounded number of times (the retried unit of work must be re-read, not replayed on stale state). If contention is genuinely high, partition ownership (one writer service) or use pessimistic locks or atomic SQL updates.

A kitchen-sink utility class has low cohesion and static coupling that hampers testing. Split by concept into focused types (MoneyUtils, a Slugifier service), prefer instance behavior on the domain type, and use the JDK or Apache/Guava utilities rather than rewriting them.

Check waitDurationInOpenState (too long), automaticTransitionFromOpenToHalfOpenEnabled (without it the transition occurs only on the next call), permittedNumberOfCallsInHalfOpenState too small to prove recovery, slow-call thresholds too aggressive, or the fallback masking success so trial calls never succeed.

A pipeline/Template Method fixes the sequence (tax -> shipping -> discount) in one orchestration class, and each step is a Strategy chosen by country from a registry. The skeleton stays stable while implementations vary per country, avoiding both a giant switch and an inheritance explosion.