Priyank Chheda

Chain of Responsibility Design Pattern in Go

Mon, 18 May 2026 00:00:00 +0000

Think about an HTTP request hitting your API server. Before the actual business logic runs, several things need to happen: authentication verifies the token, authorization checks permissions, rate limiting ensures the client hasn’t exceeded their quota, request validation confirms the payload is well-formed, and logging records the request for observability. Each check can either pass the request along or reject it outright.

The naive approach is a nested if/else tree inside the handler. Authentication passes? Check authorization. Authorization passes? Check rate limit. Rate limit passes? Validate the payload. Each new concern adds another nesting level, and the handler becomes a 200-line function that does six different things.

Simple Factory Design Pattern in Go

Mon, 30 Jun 2025 00:00:00 +0000

Think about a notification service. It needs to send messages through different channels – email, SMS, push notifications, Slack. The channel is determined at runtime: a user’s preference, a config value, a feature flag. The sending logic differs per channel, but the caller just wants to say “send this message through the right channel” without knowing how each channel works internally.

The naive approach scatters if/else chains across every call site. Each function that needs to send a notification decides which struct to instantiate, how to configure it, and which method to call. Add a new channel – webhook, for instance – and you’re modifying five different files. Remove one and you’re grepping the codebase for direct references.

Builder Design Pattern in Go

Wed, 18 Jun 2025 00:00:00 +0000

Think about constructing an HTTP client. It needs a base URL, a timeout, retry configuration, authentication headers, a transport with TLS settings, maybe a rate limiter, maybe a custom logger. Some of these are required. Most are optional. Many interact – retries without a timeout is dangerous, TLS settings without HTTPS in the base URL is a misconfiguration.

The straightforward approach is a constructor with twelve parameters. Nobody remembers parameter order. Half the call sites pass zero values for options they don’t care about. Changing the constructor signature breaks every caller. Adding validation means the constructor becomes a 50-line function that does too many things.