Go Developer Interview Questions

Go offers two distinct memory allocation primitives: new and make.

new(T)

new is a built-in function that allocates memory, but unlike in many other languages, it does not initialize the memory; it only zeroes it.

make(T, args)

make is used solely to allocate and initialize slices, maps, and channels.

Value vs. Pointer Semantics

Choosing when to pass values or pointers depends on the semantic behavior required:

1. Value Semantics: The data is copied when passed to functions or methods. This is safe, prevents accidental side effects, and is highly efficient for small read-only data structures (like standard primitives or small structs).

2. Pointer Semantics: The memory address is passed. Use pointers when:

Go interfaces are unique because they are satisfied implicitly, rather than explicitly.

Implicit Satisfaction

Method Sets and Interface Satisfaction

Whether a type satisfies an interface depends on its method set:

Empty Interface (any)

Go uses lexical scoping, meaning variables declared in outer blocks are visible in inner blocks. However, if a variable is redeclared inside an inner block, the inner variable shadows the outer one.

How Shadowing Happens with :=

The short variable declaration operator := is convenient because it declares and initializes variables in one step. However, := must declare at least one new variable. If used inside a nested scope (such as an if statement, for loop, or switch block), it will create a new variable in that nested scope, even if a variable with the exact same name exists in the outer scope.

Common Shadowing Hazard (Error Handling)

A classic shadowing bug involves error variables:

`go

func process() error {

var err error

if cond {

// Shadowing happens here! err is redeclared inside the if scope.

data, err := getData()

if err != nil {

return err

}

_ = data

}

// This err is still nil because the outer err was never updated!

return err

}

In this example, data, err := getData() creates a new err variable inside the if scope. The outer err remains nil, leading the function to falsely report success.

How to Detect and Avoid Shadowing

1. Use explicit var declarations or standard assignment (=): Declare variables beforehand and assign values using = in inner scopes when you want to modify the outer variable.

2. Check scope boundaries: Pay close attention to := inside block initializers (e.g., if err := init(); err != nil).

3. Use linters: Go tooling provides the shadow analyzer. You can run go vet with the shadow tool to inspect potential variable shadowing bugs during build pipeline checks.

An interface variable in Go holds two things: a concrete value and the concrete type of that value. To recover the underlying value or check its concrete type, Go provides type assertions and type switches.

Type Assertions

A type assertion takes the form x.(T), where x is an interface and T is a type.

Type Switches

A type switch is a control flow structure that allows you to compare the interface's concrete type against multiple case types.

Go allows you to define methods on both value and pointer receivers. Understanding the difference is crucial for program correctness and satisfying interfaces.

Value vs. Pointer Receivers

Method Sets & Interface Satisfaction

The Go language specification defines strict rules for method sets, which dictate interface satisfaction:

1. For a value type T: The method set consists of only methods declared with a value receiver (t T). It does not include pointer receiver methods.

2. For a pointer type *T: The method set consists of all methods declared with both value and pointer receivers.

Implications for Interface Satisfaction

If an interface requires a method implemented with a pointer receiver (*T), only *T satisfies the interface. If you attempt to assign a value of type T to the interface, compilation will fail.

Syntax Sugar: Automatic Referencing

When calling methods directly on variables (rather than through interfaces), Go provides convenience: if you call a pointer method on a value variable, Go automatically takes the address under the hood (e.g., t.PointerMethod() becomes (&t).PointerMethod()), provided the value is addressable.

Designing Go APIs for production requires understanding Go's philosophy of composition, implicit interface satisfaction, and performance.

1. Accept Interfaces, Return Concrete Types

2. Define Small Interfaces Near the Consumer

In Go, interfaces belong in the package that uses them (the consumer), not the package that implements them. They should be small—often containing just one or two methods (e.g., Writer, Reader). This is only possible because of implicit satisfaction.

3. Avoid Mocking-Driven Interfaces

Do not define an interface for every concrete struct simply to support testing mocks. Doing so results in bloated APIs and hides implementation details. Instead, mock using real dependencies (e.g., HTTP test servers, temporary databases) or define local interfaces only for the specific subset of behaviors you need to mock in unit tests.

4. Choose Value vs. Pointer Receivers Consistently

Do not mix pointer and value receivers on the same type. If a type needs pointer receivers for mutation or state representation, declare all of its methods on pointer receivers. If the type is read-only and represents basic data, use value receivers.

5. Avoid Pointers to Interfaces

An interface value is already a header/descriptor containing pointer references under the hood. Passing a pointer to an interface (*MyInterface) is almost always a design error and adds unnecessary pointer indirection.

6. The Typed Nil Pointer Interface Bug

An interface value is only nil if both its dynamic value and dynamic type are nil. If you store a concrete nil pointer (e.g., a nil *MyStruct) inside an interface, the interface itself is not nil (i == nil evaluates to false). Calling methods on it will execute, but will panic when dereferencing nil fields.

7. Allocation and Escape Analysis

Avoid making premature allocation claims. The compiler's escape analysis determines whether variables live on the stack or escape to the heap. To analyze actual allocation patterns, run go build -gcflags="-m" and write representative benchmarks.

Arrays and slices are related but have different semantics in Go.

Arrays

An array has a fixed length that is part of its type.

`go

var values [3]int

[3]int and [4]int are different types.

Assigning an array copies the array value according to Go value semantics.

Slices

A slice represents a sequence of elements backed by underlying storage.

`go

values := []int{10, 20, 30}

A slice has two important observable properties:

Slices are commonly used instead of arrays when collection size needs to vary.

Slicing can share storage

For example:

`go

values := []int{1, 2, 3, 4}

subset := values[1:3]

subset[0] = 99

Because subset and values can refer to the same backing array, the mutation may also be visible through values.

Do not assume creating a subslice copies its elements.

append

append returns the resulting slice:

`go

values = append(values, 40)

If enough capacity exists, the result may continue using the existing backing array.

If more capacity is required, append may allocate new backing storage and copy existing elements.

Therefore callers must use the returned slice.

This is wrong:

`go

append(values, 40)

because the returned slice header is ignored.

Aliasing matters

Two slices sharing backing storage can produce unexpected mutations when code assumes they are independent.

If independent storage is required, copy the data deliberately.

For example:

`go

clone := append([]int(nil), values...)

or use the standard-library cloning utilities appropriate to the Go version and design.

Nil and empty slices

A nil slice has zero length and zero capacity and can usually be ranged over and appended to normally.

A non-nil empty slice also has length zero, but nil and non-nil empty slices are not identical in every context, such as some serialization or API contracts.

Do not introduce unnecessary empty-slice initialization unless the API requires a specific representation.

The important interview concept is that a slice is not an automatically independent dynamically sized array. Its relationship to backing storage affects mutation, append behavior, memory retention, and API design.

A Go map associates keys with values.

For example:

`go

scores := map[string]int{

"alice": 10,

}

Key requirements

A map key type must support Go equality comparison according to the language rules.

Common key types include:

Slices, maps, and functions cannot generally be used directly as map keys because they are not comparable in the required sense.

Lookup and zero values

A map lookup returns the zero value of the element type when a key is absent:

`go

score := scores["missing"]

If the element type is int, score is 0.

That alone does not tell you whether the key was missing or explicitly stored with value zero.

Use the comma-ok form when the distinction matters:

`go

score, ok := scores["alice"]

ok reports whether the key was present.

Nil maps

A nil map can be read from safely according to normal map lookup semantics.

However, assigning a new entry to a nil map causes a runtime panic.

Initialize a map before inserting:

`go

scores := make(map[string]int)

or with a map literal.

delete

Use the built-in delete function to remove an entry:

`go

delete(scores, "alice")

Deleting a missing key is safe.

Map iteration order

Do not depend on map iteration producing a stable ordering.

If deterministic presentation or processing order matters, collect and sort the relevant keys or values explicitly.

Maps are reference-like descriptors but remain Go values

Passing a map to a function allows both caller and callee to refer to the same underlying map data.

A function can therefore mutate entries without receiving *map[K]V.

Pointers to maps are rarely necessary for ordinary mutation.

Concurrency

Ordinary Go maps are not a substitute for synchronization.

Concurrent access involving writes requires an appropriate synchronization/ownership strategy.

That subject belongs more deeply in the concurrency topic, but developers should not infer thread safety from convenient map syntax.

Use maps when the domain requires keyed lookup, and make absence semantics explicit when the element zero value is also meaningful.

Go generics allow functions and types to be parameterized by types while preserving compile-time type checking.

Generic functions

For example:

`go

func First[T any](

values []T,

) (T, bool) {

if len(values) == 0 {

var zero T

return zero, false

}

return values[0], true

}

T is a type parameter.

A caller using []string receives a string, while a caller using []User receives a User.

There is no need to convert the result through any and perform a runtime assertion.

Constraints

A type parameter has a constraint describing which types are permitted and which operations generic code may safely use.

The broad constraint:

`go

T any

permits any type but does not give the generic implementation additional operators beyond those valid for all types.

comparable

The predeclared constraint comparable permits types whose values support equality comparison in the manner required by the language for the constraint.

This is particularly useful for generic map keys:

`go

func HasKey[

K comparable,

V any,

](

values map[K]V,

key K,

) bool {

_, ok := values[key]

return ok

}

Type sets

Constraint interfaces can describe sets of permitted types.

For example, a numeric constraint may use unions and underlying-type terms where appropriate.

`go

type Integer interface {

~int | ~int32 | ~int64

}

The ~int term includes defined types whose underlying type is int.

This distinction is important when APIs should support named domain types rather than only the exact predeclared type.

Use the smallest meaningful constraint

Do not overconstrain a generic API.

If the implementation needs only equality, require only the appropriate comparable relationship rather than a larger custom interface unrelated to the algorithm.

Likewise, do not use any when the implementation genuinely requires operations unavailable for every type.

Generics do not eliminate interfaces

Generics and interfaces solve overlapping but different design problems.

Generics are especially useful when preserving relationships among concrete types matters.

Runtime interface values remain appropriate when implementations need to vary dynamically behind an interface contract.

Choose based on API semantics rather than assuming generics replace all interface-based abstraction.

Go handles ordinary recoverable failures using values implementing the built-in error interface.

A common pattern is:

`go

value, err := load()

if err != nil {

return err

}

Errors participate in normal control flow rather than using exceptions for ordinary error propagation.

Creating errors

For a simple static error value:

`go

var ErrNotFound =

errors.New("not found")

A sentinel error can be useful when callers genuinely need to branch on a stable failure category.

Do not create exported sentinel errors for every possible message.

Adding context

When propagating a lower-level error, add useful operation context:

`go

return fmt.Errorf(

"load candidate %q: %w",

id,

err,

)

%w wraps the underlying error so callers can inspect the error chain.

errors.Is

Use errors.Is when determining whether an error chain represents a target error:

`go

if errors.Is(

err,

ErrNotFound,

) {

// Handle absence.

}

Do not depend on exact formatted error strings for program control flow.

errors.As

Use errors.As when the caller needs an error matching a particular error type within the chain.

For example, a typed error may contain structured fields relevant to recovery.

Wrapping is part of an API contract

When an API wraps and exposes an underlying error with %w, callers can begin depending on that error identity or type.

Do not expose implementation-specific errors casually if you may want to change the implementation without changing the public error contract.

Sometimes translating an infrastructure error into a package-level semantic error is more appropriate.

Add context without duplication

Each layer should add information it uniquely knows.

Avoid producing messages such as:

`text

failed: failed: failed: database failed

because every layer prepended generic text.

Useful context often identifies the operation or resource.

Handle an error at the right layer

If a function cannot meaningfully recover, returning the error is often better than logging it and returning it again.

Logging at every layer creates duplicate noise.

A caller with enough context to decide the user-visible or operational outcome is usually the better place to handle or log the final failure.

The standard library demonstrates Go interface design particularly well through small interfaces such as io.Reader and io.Writer.

Conceptually:

`go

type Reader interface {

Read(p []byte) (

n int,

err error,

)

}

and:

`go

type Writer interface {

Write(p []byte) (

n int,

err error,

)

}

These interfaces do not care whether bytes come from or go to:

Composition

Because APIs depend on small capabilities rather than specific storage implementations, components can be connected together.

For example:

`go

_, err := io.Copy(

destination,

source,

)

works with values satisfying the corresponding reader and writer contracts.

Streaming

Streaming lets programs process data incrementally instead of requiring the complete input to be loaded into memory first.

This can matter for:

Read semantics require care

Read returns both a byte count and an error.

Code must respect the returned n and should not assume that every successful call fills the provided buffer completely.

The io package provides helpers for many common reading and copying patterns so application code does not need to reinvent them.

EOF

io.EOF represents an end-of-input condition according to io.Reader conventions.

Callers should use the relevant helper/API contract rather than converting every EOF occurrence into an application failure automatically.

Buffering

bufio.Reader and bufio.Writer can reduce calls to underlying I/O resources and provide additional buffered operations.

A buffered writer must be flushed when required by its lifecycle and API contract.

Close ownership

Reading or writing through an interface does not by itself say who owns the underlying resource or who should close it.

For example, a function accepting io.Reader generally should not assume it owns a file descriptor merely because the concrete value happens to be an *os.File.

Keep resource ownership explicit.

Small interfaces improve substitution naturally

A function accepting io.Writer can be tested with an in-memory buffer without inventing a large custom mock abstraction.

This illustrates an important Go API design principle: depend on the smallest capability actually required.

Production Go API design should optimize first for clear semantics and ownership, then use measurement to address real performance costs.

1. Choose collections from the required semantics

Use a slice when order and sequential collection behavior matter.

Use a map when keyed lookup is the core requirement.

Do not introduce a map merely because lookup can be fast if deterministic order or duplicate entries are essential to the domain.

2. Make slice ownership clear

Slices can share backing arrays.

An API receiving or returning a slice should have understandable mutation semantics.

Ask:

If isolation matters, copy deliberately.

Do not defensively copy every slice without reason; copying has a cost and should correspond to an ownership requirement.

3. Avoid accidental large-memory retention

A small subslice can keep a much larger backing array reachable.

For long-lived data derived from a tiny portion of a very large buffer, copying the required data may reduce retained memory.

Measure the actual retention before introducing widespread copying.

4. Treat map absence explicitly

When a map element zero value is semantically valid, use the comma-ok result where presence matters.

Do not encode several different domain states into an ambiguous zero value accidentally.

5. Do not expose map iteration order as an API contract

If an API promises deterministic ordering, produce it explicitly rather than relying on map traversal behavior.

6. Introduce generics for repeated type-safe algorithms or data structures

Good generic candidates have real relationships among their types.

Examples can include:

A generic abstraction should remove meaningful duplication without making ordinary code harder to read.

7. Constrain only what you use

If an algorithm needs equality, encode the appropriate constraint.

If it only stores and returns values, any may be enough.

Avoid broad custom constraints based on speculative future operations.

8. Do not use generics as a replacement for runtime polymorphism

When a service implementation needs to vary dynamically at runtime, a small interface may be the better abstraction.

When an algorithm must preserve static relationships among input and output types, generics may be better.

The two techniques can coexist.

9. Design error contracts deliberately

An error returned from a package is part of observable API behavior.

Decide whether callers should be able to distinguish:

Do not expose every internal database or network error simply because %w makes wrapping easy.

10. Wrap only when the underlying error should remain inspectable

Using %w intentionally exposes an error in the wrapping chain.

If the implementation detail should not become part of the caller contract, translate the failure instead and retain detailed diagnostics internally where appropriate.

11. Do not branch on formatted error strings

Use stable sentinel errors, typed errors, errors.Is, errors.As, or package-specific APIs according to the contract.

Error text is primarily for humans and can change as context is added.

12. Add context at useful boundaries

A low-level file helper knows file information.

A repository knows which entity operation failed.

A transport handler knows which request was being served.

Each layer should add only the context it uniquely owns instead of repeating generic failure language.

13. Reuse standard-library interfaces

If an API only needs to consume bytes, io.Reader may be enough.

If it only produces bytes, io.Writer may be enough.

Small established interfaces can reduce coupling and make tests straightforward.

Do not create a custom ten-method interface around a two-method requirement.

14. Keep resource ownership explicit

Accepting io.Reader does not imply ownership of its underlying file or socket.

A function should close resources it creates or explicitly owns, not arbitrary resources supplied by callers unless the API contract says otherwise.

15. Stream when full materialization is unnecessary

Large files and HTTP bodies often benefit from incremental processing.

But do not complicate tiny operations with streaming abstractions when complete materialization is harmless and simpler.

16. Use zero values where they produce useful APIs

Idiomatic Go types often make their zero value useful when practical.

However, do not force a zero value to represent a valid domain object if doing so violates important invariants.

17. Avoid performance folklore

Do not assume:

Compiler behavior evolves.

Use benchmarks, profiles, escape analysis, and real workload measurements before reshaping APIs around allocation assumptions.

18. Optimize for maintainable contracts

A strong package API makes clear:

Those semantic contracts are usually more important than clever collection or generic abstractions.

A goroutine is an independently executing function managed by the Go runtime.

A goroutine is started with the go statement:

`go

go processJob(job)

The calling goroutine continues without waiting for processJob to finish.

Concurrency does not guarantee parallel execution

Goroutines allow work to make progress concurrently, but whether multiple goroutines execute simultaneously depends on runtime scheduling, available processors, blocking behavior, and the workload.

Do not define concurrency simply as parallel execution.

The program does not automatically wait for goroutines

When the main function returns, the program terminates even if other goroutines are still running.

Applications therefore need explicit synchronization or lifecycle ownership where work must finish before shutdown.

Goroutine lifetime should be understandable

For every goroutine, developers should be able to answer:

A goroutine without a termination path can become a goroutine leak.

Goroutine leaks

A common leak occurs when a goroutine blocks forever while waiting on:

For example:

`go

func worker(results chan<- Result) {

result := compute()

results <- result

}

If nobody will ever receive from results, the goroutine can remain blocked.

Cancellation

Long-lived operations commonly accept context.Context so callers can signal that the work is no longer needed.

The goroutine must still cooperate with cancellation by observing the context or using APIs that do so.

Do not start goroutines merely to make code asynchronous

A function that starts hidden background work becomes responsible for that work's failure, ownership, cancellation, and shutdown semantics.

Prefer keeping lifecycle explicit rather than scattering go statements throughout helper functions.

A Go channel provides typed communication between goroutines.

Create an unbuffered channel with:

`go

ch := make(chan int)

or a buffered channel with:

`go

ch := make(chan int, 10)

Unbuffered channels

A send on an unbuffered channel cannot complete until a receiver is ready to receive the corresponding value, and vice versa according to channel synchronization semantics.

This makes an unbuffered channel both a communication mechanism and a synchronization point.

Buffered channels

A buffered channel can hold values up to its capacity.

A sender can proceed while buffer capacity remains available.

Once the buffer is full, another send blocks until space becomes available.

Buffering changes synchronization behavior; it should not be used merely to hide a lifecycle bug.

Channel direction

Function parameters can restrict operations:

`go

func produce(out chan<- Job)

means send-only, while:

`go

func consume(in <-chan Job)

means receive-only.

Directional channel types make API intent clearer and let the compiler prevent accidental misuse.

Closing channels

Closing a channel signals that no more values will be sent.

Receivers can continue receiving values already buffered before observing the closed state.

A receive can use:

`go

value, ok := <-ch

where ok is false when the channel is closed and drained.

range over a channel

`go

for value := range ch {

process(value)

}

continues receiving until the channel is closed and drained.

If the channel is never closed and no more values arrive, the loop can wait forever.

Who closes the channel?

The sending side that knows no additional values will be produced is generally the appropriate owner of closure.

Receivers should not close a channel merely because they no longer want values unless the ownership protocol explicitly gives them that responsibility.

Closing is not required for every channel

A channel does not need to be closed simply to release resources.

Close is a communication signal indicating that no more values will be sent.

Use it only where that semantic signal matters.

select coordinates multiple channel operations.

For example:

`go

select {

case value := <-results:

return value, nil

case <-ctx.Done():

return Result{}, ctx.Err()

}

The goroutine can proceed when either a result arrives or cancellation occurs.

select chooses among ready cases

If one communication case is ready, it can proceed.

If multiple cases are ready, Go chooses one that can proceed rather than providing application-level priority based on case order.

Do not rely on textual case ordering as a priority mechanism.

default

A default case makes a select non-blocking when no communication case is ready.

For example:

`go

select {

case value := <-ch:

use(value)

default:

// Nothing available now.

}

A default inside a tight loop can create busy spinning and consume CPU.

context.Context

Context carries request-scoped cancellation, deadlines, and values across API boundaries.

Functions doing request-scoped work commonly accept context as their first argument:

`go

func Load(

ctx context.Context,

id string,

) error

Cancellation propagation

When a parent context is canceled, contexts derived from it are canceled as well.

This helps terminate trees of request-related work.

Code must still cooperate with cancellation either by:

Timeouts and deadlines

Use helpers such as context.WithTimeout or context.WithDeadline when the caller owns the time budget.

The corresponding cancel function should normally be called to release associated resources:

`go

ctx, cancel :=

context.WithTimeout(

parent,

time.Second,

)

defer cancel()

Do not store Context in ordinary structs by default

Pass context explicitly through the call chain so request lifetime remains clear.

Context values are not general dependency injection

Use context values for request-scoped data that must cross API/process boundaries, not as an arbitrary bag for services, configuration, or optional function parameters.

Timeout ownership

Avoid blindly placing a fixed timeout at every layer.

A higher layer often owns the overall request budget, while lower layers should respect the remaining context deadline.

Cancellation should describe useful lifecycle semantics rather than merely serving as another error path.

The sync package provides synchronization primitives for shared-memory concurrency.

Channels are valuable, but Go does not require every concurrency problem to be expressed through channels.

sync.Mutex

A mutex protects a critical section involving shared state.

`go

type Counter struct {

mu sync.Mutex

n int

}

func (c *Counter) Add() {

c.mu.Lock()

defer c.mu.Unlock()

c.n++

}

Only one goroutine should access the protected critical section at a time according to the mutex protocol.

Keep the protected invariant clear

A mutex should protect specific state or an invariant.

Do not scatter unrelated lock operations throughout code without knowing what state the lock protects.

Do not copy used mutexes

Types containing synchronization primitives such as sync.Mutex should not be copied after first use.

This is one reason methods on such state-owning structs commonly use pointer receivers.

sync.RWMutex

RWMutex permits multiple readers or one writer according to its locking semantics.

It is not automatically faster than Mutex.

Use it when measured workload and contention patterns justify the additional complexity.

Do not introduce RWMutex merely because a structure performs many reads in source code.

sync.WaitGroup

A WaitGroup waits for a collection of goroutines or operations to finish.

Typical usage historically follows the pattern of adding expected work, calling Done when each goroutine completes, then waiting.

The synchronization counter must be managed correctly; misuse can result in panics or incorrect waiting behavior.

Use the APIs available in the project's Go version according to their documented contract.

WaitGroup does not propagate errors

Waiting for completion does not by itself collect worker errors, cancel sibling work, or enforce resource limits.

If those semantics are required, add them explicitly through context, result channels, or an appropriate higher-level design.

Channels versus mutexes

A useful role is not simply:

`text

channels good, mutexes bad

Instead ask what the problem represents.

A mutex is often straightforward when several goroutines must safely access one shared in-memory structure.

A channel is often useful when the design naturally represents ownership transfer, event delivery, or pipeline communication.

The simpler model that preserves correctness is usually preferable.

Concurrent Go programs need more than an intuitive assumption that one goroutine probably runs before another.

The Go memory model defines synchronization and visibility rules for concurrent accesses.

Data race

A data race can occur when multiple goroutines access the same memory concurrently, at least one access writes, and the accesses are not ordered by the required synchronization relationship.

For example:

`go

var count int

go func() {

count++

}()

go func() {

count++

}()

contains unsynchronized shared mutation.

The fact that count++ looks like one source-level operation does not make it an atomic synchronization operation.

Synchronization establishes ordering

Operations involving synchronization primitives can establish ordering relationships defined by Go.

Relevant mechanisms include appropriate use of:

Do not build concurrency correctness around timing, sleeps, or assumptions about scheduler behavior.

Channel synchronization

Channel send/receive operations provide synchronization relationships according to the memory-model rules.

This is one reason channels can safely transfer data ownership when designed correctly.

Mutex synchronization

Unlocking and subsequently locking the same synchronization primitive according to its documented rules provides the ordering needed to make protected state visible safely.

Race detector

Go provides the race detector through commands such as:

`text

go test -race ./...

and instrumented program builds/runs.

It detects data races that occur during the execution paths exercised while instrumentation is active.

Passing the race detector does not prove the program is race-free

If a problematic execution path never occurs during the test or run, the detector cannot report that particular race.

Use representative concurrent workloads to improve coverage.

Race detector findings are correctness issues

Do not suppress or ignore a race report simply because the program appears to work.

Data races can cause nondeterministic behavior and invalidate assumptions about memory visibility.

Race-free does not mean logically correct

A program can contain no data race yet still have higher-level concurrency bugs such as:

The memory model protects synchronization semantics, not complete application correctness.

Production Go concurrency is primarily an ownership and lifecycle design problem.

Starting a goroutine is easy. Ensuring thousands of goroutines stop correctly under success, failure, timeout, shutdown, and overload is the harder engineering work.

1. Every goroutine needs an owner and exit condition

For each goroutine, define:

Avoid fire-and-forget goroutines unless their process-lifetime semantics are intentional and documented.

2. Propagate request cancellation

Request-scoped operations should usually accept context.Context and propagate it through network, database, and internal calls.

If the client disconnects or the request deadline expires, downstream work should stop when possible instead of continuing expensive work whose result nobody will use.

3. Do not create independent background contexts inside request work

Replacing the caller context with context.Background() can accidentally detach work from cancellation.

Only detach lifetime when the product semantics explicitly require work to continue independently.

4. Bound concurrency

Do not start one goroutine per item without considering input size.

For ten items, that may be fine.

For ten million items, it may produce excessive:

Use bounded worker pools, semaphores, fixed concurrency, or batching when resource capacity requires it.

The appropriate limit should come from workload and dependency capacity rather than an arbitrary universal number.

5. Design backpressure

If producers generate work faster than consumers can process it, the system needs a policy.

Possible approaches include:

An enormous channel buffer merely postpones overload and consumes memory.

6. Channels communicate ownership and events

Channels work well when one component produces values for another or when an event/pipeline relationship is natural.

Avoid using a channel as a complicated remote-control interface for an object when a synchronized method call would be clearer.

7. Close channels according to ownership

The component responsible for completing production normally closes the channel.

Consumers should not close producer-owned channels simply because they are no longer interested.

Cancellation is often the better signal for consumers to indicate lost interest.

8. Protect shared mutable state deliberately

If multiple goroutines share a cache or state structure, choose one clear model:

Do not mix several ownership models casually around the same state.

9. Do not hold locks across arbitrary external work

A lock held during:

can create contention or deadlock chains.

Capture required state under the lock, release it where semantics allow, perform slow work, then reacquire and revalidate if necessary.

10. Make error propagation explicit

A WaitGroup tells you that goroutines finished; it does not tell you whether they succeeded.

For concurrent operations, define whether:

The synchronization primitive should not accidentally determine product semantics.

11. Avoid blocked-result goroutines

A common failure pattern is:

`text

caller times out

→ returns

→ worker finishes

→ worker blocks forever sending result

Possible solutions include cancellation-aware sends, appropriately bounded result channels, or architectural changes where the worker does not require an abandoned receiver.

12. Shutdown should be designed, not improvised

On process shutdown:

1. Stop accepting new work.

2. Signal cancellation where appropriate.

3. Allow bounded graceful completion.

4. Close producer-owned resources/channels.

5. Wait for owned goroutines.

6. Enforce an overall shutdown deadline.

Do not assume all goroutines disappear cleanly because the HTTP server stopped accepting connections.

13. Avoid circular waiting

Deadlocks often emerge when components wait on one another through combinations of:

Keep ownership relationships directional and minimize nested synchronization.

14. Use race detection routinely

Run concurrent tests with:

`text

go test -race ./...

especially after modifying shared state, worker pools, caches, or request lifecycle handling.

Race detection complements normal tests; it does not replace architectural reasoning.

15. Observe production behavior

Useful operational signals can include:

A steadily increasing goroutine count can indicate leaks, but diagnose the blocked stacks and ownership flow before assuming the cause.

16. Capture goroutine profiles when needed

Go profiling and runtime diagnostics can reveal goroutines blocked in channel operations, locks, network I/O, and other states.

Use these tools to diagnose real production behavior rather than guessing from source code alone.

17. Prefer sequential code until concurrency creates real value

Concurrency increases the number of possible execution orders.

If sequential processing meets latency and throughput requirements, it may be safer and easier to operate.

Introduce concurrency for a measured reason such as independent I/O overlap, throughput, or responsiveness.

18. Make overload behavior part of architecture

A service is not resilient merely because it works at normal traffic.

Define what happens when demand exceeds capacity.

Bounded systems fail more predictably than systems that create unlimited goroutines and buffers until memory is exhausted.

A strong Go concurrency architecture makes lifecycle, resource limits, ownership, cancellation, and failure behavior understandable before production load tests expose them.

Go HTTP servers are built around the net/http package and the http.Handler abstraction.

Handler interface

A handler implements:

`go

type Handler interface {

ServeHTTP(

ResponseWriter,

*Request,

)

}

A function can become a handler through http.HandlerFunc.

`go

func health(

w http.ResponseWriter,

r *http.Request,

) {

w.WriteHeader(

http.StatusOK,

)

}

ResponseWriter

The handler writes response headers, status, and body through http.ResponseWriter.

Headers generally need to be configured before the response status/body is committed.

If WriteHeader is not called explicitly, writing the body normally causes an implicit successful status to be sent.

Request

*http.Request contains request information such as:

A request handler should validate only the semantics required by its endpoint rather than assuming all requests are trustworthy.

http.Server

Production applications often construct an explicit http.Server rather than relying only on convenience serving functions.

This allows configuration of operational behavior including appropriate timeout and header limits.

Relevant settings include concepts such as:

The correct values depend on workload, protocols, clients, and deployment environment.

Do not copy universal timeout numbers into every service without understanding their behavior.

Graceful shutdown

A production service should normally have an intentional shutdown path.

Server.Shutdown can stop accepting new connections while allowing active work an opportunity to complete within the supplied context deadline.

Application-owned workers and resources still need their own shutdown coordination.

Stopping the HTTP server does not automatically guarantee that every goroutine, database operation, queue worker, or background process has terminated.

Keep handlers bounded

A handler should not start indefinite background work whose ownership becomes detached from the request unless the application explicitly transfers that work to a longer-lived subsystem.

Request handlers are an adapter boundary: parse HTTP input, call application logic, and translate the result back into an HTTP response.

HTTP middleware wraps one handler with additional request/response behavior.

A common shape is:

`go

func Middleware(

next http.Handler,

) http.Handler

This allows cross-cutting transport behavior to be composed without copying it into every endpoint.

Common middleware responsibilities include:

Do not move unrelated domain behavior into middleware merely because middleware is globally reachable.

Request context

Every server request has a context available through:

`go

ctx := r.Context()

That context represents request-scoped lifetime information.

Pass it into downstream operations that belong to the request:

`go

candidate, err :=

service.Load(

r.Context(),

id,

)

Database and outbound HTTP APIs commonly provide context-aware operations so cancellation and deadlines can propagate.

Client disconnect and cancellation

Request context can become canceled when request processing should stop, including relevant connection/request lifecycle events.

Code should not assume that a canceled request means every downstream operation stops instantly; downstream components must support or observe cancellation.

Do not replace request context unnecessarily

This defeats propagation:

`go

service.Load(

context.Background(),

id,

)

when the operation actually belongs to the request.

Use a separate lifetime only when the application intentionally transfers work out of request ownership.

Context values

Middleware can attach genuinely request-scoped metadata to a context.

Keys should avoid collisions and values should remain limited to data that truly belongs to the request boundary.

Do not place database handles, configuration trees, or every service dependency into context as a general dependency-injection mechanism.

Middleware ordering matters

Wrapping order affects behavior.

For example, request identification may need to happen before logging so logs include the identifier.

Authentication may need to execute before an authorization-dependent endpoint.

Treat middleware composition as an explicit pipeline.

An HTTP API boundary should separate transport parsing from application semantics.

Use explicit request types

For example:

`go

type CreateCandidateRequest struct {

Name string json:"name"

Email string json:"email"

}

Then decode through encoding/json.

Do not decode arbitrary request bodies directly into persistence models simply because their current fields happen to match.

Decoding is not business validation

Successful JSON decoding means the input was compatible with the decoder and target representation.

It does not prove that:

Keep structural decoding and semantic validation conceptually separate.

Unknown fields

For APIs that want strict input contracts, a decoder can reject unknown object fields where appropriate.

Whether to do so is an API compatibility decision rather than a universal rule.

Strict rejection can catch client mistakes but can also affect forward/backward compatibility strategies.

Limit request bodies

Do not read arbitrarily large untrusted JSON into memory without considering limits.

HTTP services should establish appropriate request-size policies according to endpoint requirements.

One logical JSON value

Endpoints expecting one JSON document should avoid accidentally accepting trailing unrelated JSON values merely because the first decode succeeded.

Validation of framing should match the endpoint contract.

Response structure

Return consistent JSON response shapes where possible.

Set response headers such as content type before committing the response.

Map application semantics to appropriate HTTP status categories deliberately.

For example:

should not automatically collapse into one generic successful response or one arbitrary status.

Do not expose internal errors blindly

Database driver text, filesystem paths, SQL details, tokens, and internal stack information generally do not belong in client-facing error bodies.

Log useful internal diagnostics at the operational boundary and return a stable public error representation.

Transport DTOs protect boundaries

Request/response types can evolve according to the HTTP contract while domain models remain focused on application semantics.

database/sql provides a standard interface for relational database access through database drivers.

sql.DB is not one connection

A *sql.DB represents a database handle that manages a pool of underlying connections.

It is designed to be shared and reused by concurrent application operations.

Do not open a new sql.DB for every HTTP request.

Connection pooling

The pool creates and reuses connections according to workload and configured limits.

Relevant controls include concepts such as:

These settings interact with:

Do not copy a pool size from another service without capacity reasoning and measurement.

Context-aware operations

Use methods such as:

`go

QueryContext

ExecContext

BeginTx

when work belongs to a request or another cancellable operation.

Passing context lets supported drivers/database operations respond to cancellation and deadlines.

Rows lifecycle

When querying rows, close them when finished.

Also check errors encountered during iteration rather than assuming successful initial query execution guarantees successful consumption of every row.

Transactions

A transaction represents a group of operations that must follow the database transaction semantics.

Conceptually:

`go

tx, err := db.BeginTx(ctx, nil)

Then perform the transactional operations through tx.

Do not begin a transaction and accidentally issue one of the logically transactional queries through db, because that operation may execute on a different connection outside the transaction.

Commit and rollback

If the operation succeeds, commit.

If it fails, roll back.

A common pattern schedules rollback defensively and treats rollback after a successful commit according to the documented behavior.

Transaction scope

Do not keep a transaction open while waiting for unrelated slow network calls or user interaction.

Long transactions can hold connections and database resources, increasing contention.

Prepared statements and parameters

Use parameterized database APIs rather than building SQL by concatenating untrusted values.

Parameter syntax is driver/database specific, but values should be passed through the driver rather than manually quoted into SQL text.

A healthy data-access boundary makes transaction ownership, context lifetime, query semantics, and pool capacity visible.

Go's testing package supports simple test functions and subtests without requiring a separate testing language.

Basic test

`go

func TestValidateName(

t *testing.T,

) {

// Arrange, execute, verify.

}

Table-driven tests

Table-driven tests are useful when the same behavior should be checked across many inputs.

For example:

`go

tests := []struct {

name string

input string

want bool

}{

{

name: "valid",

input: "Alex",

want: true,

},

}

Then run each scenario as a subtest with t.Run.

Do not use table-driven structure mechanically when a single direct test is clearer.

httptest.ResponseRecorder

For handler-level tests, httptest.NewRecorder captures the response generated by an http.Handler.

httptest.NewRequest creates a server-style request suitable for handler tests.

This is useful for verifying:

without opening a real network listener.

httptest.Server

When code needs a real HTTP client/server interaction, httptest.NewServer can start a local test server.

This is useful for testing HTTP client behavior against controlled responses.

Keep business logic below HTTP test boundaries

If validation, state transitions, or mapping logic can be tested directly, do not force every permutation through JSON serialization and HTTP handlers.

That keeps most tests faster and easier to diagnose.

Integration tests

Use integration tests when confidence requires real collaboration such as:

Define clearly what infrastructure the test requires.

Deterministic dependencies

Avoid tests that depend on:

Parallel tests

t.Parallel can reduce suite duration, but only use it when tests do not conflict through shared mutable resources.

Parallelizing unsafe tests creates nondeterminism rather than useful speed.

The goal is to test behavior at the lowest level that provides the confidence the behavior requires.

A production Go service should make transport boundaries, dependency ownership, failure behavior, and resource limits understandable.

1. Keep HTTP as an adapter boundary

Handlers should primarily:

Do not place the complete business workflow directly inside ServeHTTP.

2. Keep application logic independent of HTTP where practical

A service operation such as:

`go

CreateCandidate(

ctx context.Context,

command CreateCandidate,

) (Candidate, error)

can be tested without constructing HTTP requests.

The handler converts JSON into the command and converts the result back into an HTTP representation.

3. Keep persistence behind semantic operations

A repository should expose operations meaningful to the application rather than leaking arbitrary SQL throughout handlers.

Do not introduce repositories mechanically for every table; create boundaries where they improve ownership, testing, or implementation isolation.

4. Propagate context

Request-owned database queries and outbound HTTP calls should inherit request cancellation and deadlines.

Do not detach ordinary request work with context.Background().

5. Define timeout ownership

Timeouts exist at several layers:

Avoid contradictory timeout stacks where an inner layer has a longer deadline than the useful outer operation or where every function invents an unrelated fixed timeout.

6. Bound database capacity

Remember that each sql.DB owns a connection pool.

If 20 application replicas each allow 100 database connections, theoretical demand may greatly exceed database capacity.

Pool configuration must therefore account for service replicas and database limits, not only one process.

7. Keep transactions narrow

Start a transaction around the database operations requiring transactional guarantees.

Do not hold a database transaction open during arbitrary remote API calls unless the architecture explicitly accepts the resulting resource and consistency implications.

8. Design idempotency for retried writes

A network timeout does not always tell a client whether the server completed a write before the response was lost.

Blind retrying can therefore duplicate operations such as:

Where duplicate execution is unacceptable, design an idempotency mechanism or another operation-specific deduplication strategy.

9. Retry selectively

Retries are appropriate only when:

Use bounded attempts and backoff where semantics call for it.

Do not retry validation failures or permanent authorization failures.

10. Keep public errors stable

Map internal errors into application-level categories and HTTP responses.

A PostgreSQL/MySQL/driver message should not become the external API contract accidentally.

Preserve useful internal context for logs and diagnostics.

11. Validate external input before side effects

Reject malformed or semantically invalid input before starting expensive or irreversible work where possible.

But remember that validation requiring current database state may still be subject to races; enforce critical invariants transactionally or with database constraints where appropriate.

12. Treat database constraints as correctness tools

Application validation can improve user feedback, but uniqueness, foreign-key, and transactional invariants that must hold under concurrency should be enforced at the appropriate durable boundary.

Do not assume an application-level check immediately before an insert eliminates races.

13. Test by boundary

Use focused unit tests for:

Use handler tests for:

Use integration tests for:

Use a small number of broader tests for critical complete flows.

14. Keep tests independent of production

Tests should never require production database credentials or live destructive endpoints.

Use isolated test infrastructure and deterministic data ownership.

15. Make observability useful

Operational telemetry should answer questions such as:

Avoid logging secrets, authorization headers, raw tokens, or unnecessary personal data.

16. Design graceful shutdown across components

Stopping production service traffic may involve:

1. Stop accepting new requests.

2. Allow active requests a bounded completion period.

3. Cancel application-owned workers where appropriate.

4. Stop queue consumers/producers.

5. Close resources owned by the process.

6. Wait for owned goroutines.

Use explicit deadlines so shutdown cannot hang forever.

17. Separate readiness from liveness semantics

Operational health endpoints should have clear purposes.

A service that is alive but cannot safely accept new work may need different signaling than a process that should be restarted.

Avoid making every health endpoint execute expensive dependency queries on every probe unless that behavior is intentionally required.

18. Keep architecture proportional

A small service may need:

`text

handler

→ service

→ database

not twelve abstraction layers.

Add interfaces and modules where they establish meaningful ownership, substitution, or dependency boundaries.

The objective is a service whose request lifetime, resource consumption, side effects, and failure semantics remain predictable under both normal traffic and partial failure.

Performance optimization should begin with evidence rather than assumptions.

Benchmarks

Go benchmarks are written using the testing package and conventionally use functions whose names begin with Benchmark.

A benchmark repeatedly executes the operation being measured so the testing framework can estimate its cost.

For example:

`go

func BenchmarkLookup(

b *testing.B,

) {

values := prepareData()

b.ResetTimer()

for i := 0; i < b.N; i++ {

lookup(values)

}

}

Benchmark setup that is not part of the operation being measured should generally be kept outside the timed portion where appropriate.

Compare meaningful workloads

A microbenchmark can be useful, but it does not automatically represent production behavior.

Consider realistic:

Profiling

Profiling helps identify where resources are actually being consumed.

Depending on the problem, useful profiles can include:

pprof tooling can inspect these profiles and help identify expensive call paths.

Do not optimize only from source inspection

Code that looks expensive may not dominate runtime cost.

Likewise, a small allocation repeated millions of times may matter more than a visually complicated function that runs once.

Measure before and after

A performance change should be validated against the same representative workload after implementation.

Otherwise the optimization may:

Performance work is an engineering feedback loop:

`text

observe

→ reproduce

→ benchmark/profile

→ change

→ measure again

The important interview principle is not memorizing one optimization trick. It is demonstrating disciplined measurement.

Go modules provide versioned dependency management for Go projects.

go.mod

A module is identified by its module path and described by go.mod.

The file can contain information such as:

Dependency requirements should reflect the project rather than being manually treated as an arbitrary package inventory.

go.sum

go.sum records cryptographic checksums associated with downloaded module versions and their module files.

It contributes to verifying that downloaded dependency content matches previously authenticated content.

It is not simply a list of the dependencies currently imported by application source code.

Versioned dependencies

A production project should make dependency upgrades deliberately.

An upgrade can affect:

Review significant upgrades rather than automatically assuming a newer version is behaviorally identical.

go mod tidy

Module tooling can keep module requirements and checksums consistent with the packages needed to build and test the module.

Do not run dependency-cleanup commands blindly and commit unexplained large dependency changes.

Review the resulting diff.

replace directives

A replace directive can be useful during local development or when intentionally substituting a module version/path.

Be careful not to commit accidental workstation-specific replacements that make builds depend on a developer machine.

Reproducible builds require more than dependency files

Reliable delivery also depends on factors such as:

Dependency management is therefore one component of build reproducibility rather than a complete guarantee by itself.

Go developers should reason about memory from observable behavior rather than simplistic rules such as "pointers allocate" or "values stay on the stack."

Escape analysis

The compiler analyzes whether values can safely remain within a local lifetime or must remain reachable beyond it.

A value whose lifetime requires longer-lived storage may escape.

Source syntax alone does not determine whether a value resides on the stack or heap.

For example, returning a pointer to a local variable is valid Go because the compiler/runtime ensure that the value remains alive as required.

Do not treat stack versus heap as an API semantic

Whether a particular implementation allocates can change across compiler versions and code changes.

Do not design public APIs around undocumented assumptions that one syntax form always avoids allocation.

Garbage collection

Heap objects that remain reachable contribute to the live heap and garbage-collection work.

Application memory behavior depends on factors such as:

Allocation rate versus retention

These are different problems.

A workload can allocate many short-lived objects while maintaining a modest live heap.

Another workload may allocate relatively little but accidentally retain large objects for a long time.

Profiles help distinguish these cases.

Common retention example

A small slice can retain a large backing array if it still references that storage.

If the small result must live much longer than the original buffer, making an independent copy may reduce retained memory.

But do not copy automatically without evidence or an ownership requirement.

Pooling

Reuse mechanisms such as sync.Pool can reduce allocation pressure in appropriate workloads, but they should not be introduced automatically.

Pooling adds lifecycle complexity and can make code harder to reason about.

Measure whether allocation pressure actually matters first.

Use compiler diagnostics carefully

Compiler escape-analysis output can help explain why allocations occur, but it is an implementation diagnostic rather than a stable application contract.

Combine it with benchmarks and memory profiles.

A good optimization process asks:

1. Is memory causing a measurable product or operational problem?

2. Is the issue allocation rate, retained memory, or both?

3. Which call paths dominate?

4. Can the design reduce unnecessary work without making ownership dangerous?

5. Did the change improve the measured workload?

Production debugging is more effective when different observability signals answer different questions.

Metrics

Metrics are useful for understanding trends and aggregate behavior such as:

Metrics can tell you that a problem exists but often cannot identify the exact code path responsible.

Logs

Logs can provide event-specific context such as:

Avoid logging secrets, authentication credentials, raw tokens, or unnecessary personal data.

Logging every internal error at every layer can also create duplicate noise.

Profiles

Profiles answer questions about runtime resource consumption.

Examples include:

Execution tracing

Runtime tracing can provide a more detailed view of scheduler activity, goroutines, blocking, garbage collection, and other runtime events.

Tracing can be powerful but produces more detailed data and should be collected intentionally.

Correlate signals

Suppose service latency rises while CPU remains normal but database pool waits increase.

A CPU optimization would likely target the wrong problem.

Likewise, rising goroutine counts plus goroutine profiles showing blocked channel sends may reveal lifecycle leakage.

Protect production endpoints

Diagnostic interfaces can expose sensitive operational details and may consume resources.

Do not make debugging endpoints publicly accessible merely because the standard library makes them easy to register.

Apply appropriate network, authentication, deployment, and operational controls.

Observe outcomes, not implementation trivia

Start with user/service symptoms:

`text

latency increased

error rate increased

memory keeps growing

workers stopped making progress

Then use signals to narrow the hypothesis.

A useful diagnostic loop is:

`text

symptom

→ metrics/logs

→ targeted profile or trace

→ hypothesis

→ reproduce

Observability should help engineers make decisions rather than simply produce more telemetry.

Reliable services remain predictable not only during normal traffic but also when dependencies slow down, clients disappear, and demand exceeds capacity.

Timeouts are budgets

Timeouts should reflect useful operation lifetime.

If an incoming request has a deadline, downstream database and HTTP work should generally respect the remaining request budget.

Do not independently assign every layer a longer timeout than the caller can use.

Bound resource consumption

Important resources include:

Unbounded concurrency can turn one slow dependency into a process-wide resource exhaustion event.

Backpressure

When incoming work exceeds processing capacity, define what happens.

Depending on product semantics, the system may:

Unlimited in-memory buffering is not a durable reliability strategy.

Retries

Retry only when the failure may be transient and repeating the operation is safe.

Retries should remain bounded by:

Retries can amplify an outage if every service aggressively repeats requests against an already overloaded dependency.

Idempotency

A timeout does not necessarily mean the remote operation failed.

The remote service may have completed the side effect but the response was lost.

Writes that may be retried need operation-specific idempotency or deduplication where duplicate effects are unacceptable.

Graceful shutdown

A common shutdown sequence is:

1. Stop accepting new work.

2. Signal application cancellation.

3. Allow active operations a bounded completion period.

4. Stop workers/consumers.

5. Close resources owned by the process.

6. Wait for owned goroutines.

7. Exit when complete or when the shutdown deadline expires.

Readiness

A process can still be running while temporarily unable to accept useful new work.

Operational readiness should therefore represent whether traffic should be routed to the instance according to the deployment design.

Failure isolation

Avoid letting one optional dependency make every endpoint unavailable when the product can provide degraded behavior safely.

But degraded behavior must be deliberate; silently returning incorrect data is not resilience.

Reliability is the result of explicit limits and failure semantics rather than one library or retry helper.

Production architecture is not a collection of Go-specific tricks. It is the system of ownership, contracts, limits, measurements, and delivery practices that keeps software understandable as traffic and teams grow.

1. Keep package boundaries meaningful

Organize packages around cohesive responsibilities rather than creating one package per file or one abstraction layer per concept.

A package should have a clear reason to change and a deliberate public API.

Avoid large grab-bag utility packages whose functions have unrelated ownership.

2. Keep dependency direction understandable

Transport adapters may depend on application behavior.

Application behavior may depend on small persistence or external-service contracts.

Infrastructure implements those contracts.

Do not introduce interfaces at every package boundary mechanically. Interfaces are useful when the consumer requires abstraction or substitution.

3. Make lifecycle ownership explicit

Know who owns:

Creation and shutdown should follow the same ownership structure.

4. Bound resources

Production capacity must account for:

The safest limit is not a universal constant. Determine limits from workload measurements and downstream capacity.

5. Establish performance objectives from product requirements

Do not optimize for arbitrary numbers such as every endpoint needing identical latency.

Different operations can have different requirements.

Define meaningful latency, throughput, or resource objectives, then benchmark and profile against representative workloads.

6. Diagnose before optimizing

Use metrics, profiles, traces, benchmarks, and production symptoms to identify bottlenecks.

Avoid architecture changes driven only by beliefs such as:

Measure the actual system.

7. Treat memory as an operational resource

Watch:

A cache with no eviction or ownership policy can become a memory leak at the application level even though all memory remains technically reachable.

8. Design failure domains

Ask whether an optional dependency failure must disable the entire service.

Use deliberate degraded behavior only where correctness permits it.

Circuit breakers, load shedding, retry policies, or queues are architectural tools only when they match the actual failure semantics.

Do not add resilience patterns mechanically.

9. Make writes safe under retries where required

Network failures can leave callers uncertain about whether a side effect occurred.

Critical write APIs may need:

The exact mechanism depends on the operation.

10. Keep database invariants durable

Application-level validation improves UX but does not replace database constraints for invariants that must hold under concurrency.

Use transactional and database-level guarantees where correctness requires them.

11. Keep external contracts backward compatible intentionally

Clients, other services, and deployed binaries do not necessarily upgrade at the same moment.

Evolve HTTP/event/data contracts with compatibility windows where required.

Do not assume every caller updates atomically with the server.

12. Treat database migrations as deployed compatibility changes

Application versions can overlap during rollout.

Prefer migrations and release sequences that account for old and new binaries operating during transition where the deployment model requires it.

Avoid destructive schema changes before all dependent code has stopped requiring the old representation.

13. Control dependencies

Every external module adds potential:

Prefer dependencies that materially reduce complexity or provide capabilities worth owning externally.

Review upgrades and module changes explicitly.

14. Keep binaries and containers operationally simple

Go often enables relatively self-contained service binaries, but deployment behavior still depends on configuration, certificates, network access, filesystem assumptions, architecture, and external services.

Do not confuse compilation simplicity with zero operational dependencies.

15. Design observability around decisions

Metrics and logs should help determine:

Use release/version information where useful for comparison.

16. Protect diagnostics and user data

Profiles and logs can expose operational information.

Restrict diagnostic access and avoid collecting unnecessary secrets or personal data.

17. Make rollout reversible

Production changes should have a recovery path.

Depending on the system, this can involve:

Feature flags also require ownership and cleanup; permanent abandoned flags create additional system states.

18. Test failure paths

Do not verify only successful requests.

Test meaningful conditions such as:

19. Keep architecture proportional to current constraints

Do not split a small service into many internal layers or microservices merely to imitate a larger company.

Architecture should solve observed ownership, scale, reliability, and team problems.

20. Evolve from evidence

A healthy production loop is:

`text

observe

→ identify constraint

→ form hypothesis

→ implement smallest useful change

→ test

→ deploy safely

→ measure

Go makes it easy to build straightforward systems. Preserve that advantage by adding complexity only when the product or operational evidence justifies it.