Gin Interview Questions and Answers

Answer

Gin is a high-performance HTTP web framework for Go, released in 2014. It solves three problems with the standard library's net/http: (1) routing is verbose, net/http doesn't support path parameters or method-based dispatch natively, (2) repetitive plumbing, parsing JSON, validating input, writing responses, and handling errors needs the same boilerplate in every handler, (3) middleware composition is awkward, you end up wrapping http.Handler in a chain of closures. Gin replaces this with a httprouter-derived radix tree for O(log n) route matching, a single gin.Context that exposes binding/validation/response helpers, and a clean Use()/group middleware chain.

It claims ~40× the throughput of Martini and stays competitive with Fiber and Echo in benchmarks while keeping the API surface small. Mechanically, *gin.Engine implements http.Handler, so Gin is a handler you hand to an http.Server rather than a replacement server: ReadHeaderTimeout, TLS config, HTTP/2 and srv.Shutdown all still apply exactly as in stdlib. The middleware chain is not nested closures either.

Each route stores one flat []HandlerFunc slice, and gin.Context walks it with an int8 index that c.Next() advances, which is why c.Abort() works by jumping the index past the end instead of unwinding the stack. Interviewers usually probe the boundaries next, so state them: Gin gives you routing, binding, rendering and middleware and deliberately nothing else. There is no ORM, no dependency injection, no config loader, no migrations, and no built-in graceful shutdown.

You bring database/sql or pgx or GORM, your own logger, and your own http.Server wrapper. Treat the '40x faster than Martini' line as a 2014 marketing number rather than a reason to pick Gin in 2026; the real reasons are the gin-contrib middleware ecosystem and the fact that most Go engineers can read a Gin codebase on day one.

Answer

Create a *gin.Engine via gin.Default() (includes Logger + Recovery middleware) or gin.New() (no middleware), register handlers with HTTP-verb methods, then call Run(). Each handler takes a *gin.Context. Path parameters are declared with :name and accessed via c.Param("name").

Wildcards use *name and capture the remainder of the path. Four details interviewers listen for. First, r.Run(":8080") is a thin wrapper over http.ListenAndServe(addr, engine), so it gives you no timeouts and no shutdown hook; anything going to production should construct its own http.Server with the engine as Handler.

Second, if you pass no address, Run reads the PORT environment variable and only then falls back to :8080, which is what makes a bare Gin binary work unchanged on Cloud Run and similar platforms. Third, route registration happens at startup and panics instead of returning an error, so a malformed pattern kills the process on boot rather than at the first request, and r.Routes() dumps every registered method/path/handler triple if you want a startup sanity check. Fourth, a catch-all keeps its leading slash: with /files/*path, a request to /files/a/b.txt yields c.Param("path") == "/a/b.txt", which breaks naive filepath.Join calls.

Trailing slashes are also handled for you: RedirectTrailingSlash is true by default, so /items/ redirects to /items with 301 for GET and 307 for other verbs. Clients that do not replay the body on redirect will silently lose a POST payload, so set r.RedirectTrailingSlash = false when you want a strict 404.

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()

    r.GET("/items/:id", func(c *gin.Context) {
        id := c.Param("id")
        q := c.Query("q")              // ?q=hello
        c.JSON(200, gin.H{"id": id, "q": q})
    })

    r.Run(":8080")
}

Answer

gin.Context is the per-request struct passed to every handler. It wraps the underlying http.Request and http.ResponseWriter and adds Gin-specific helpers: path/query/form parameters (Param/Query/PostForm), request body binding (ShouldBindJSON, ShouldBindQuery), response writers (JSON, XML, String), the middleware control flow (Next, Abort, IsAborted), per-request key/value storage (Set/Get) for sharing data across middleware, and access to the chain of errors via c.Errors. Crucially, the *gin.Context is only valid for the duration of the request, Gin pools and reuses them via sync.Pool, so you must NEVER store one past the handler return, and must call c.Copy() before passing it into a goroutine.

Two things a senior interviewer will push on. First, the Keys map behind c.Set/c.Get is allocated lazily on the first Set and guarded by an internal sync.RWMutex, so reading a key from a copied context in another goroutine is safe for the map itself; nothing else on the struct is protected. c.MustGet panics when the key is absent, while the typed helpers (c.GetString, c.GetInt, c.GetBool) swallow a missing key and hand back the zero value, which is how a missing user_id quietly becomes an empty string in your audit logs. Second, *gin.Context satisfies the context.Context interface (Deadline, Done, Err, Value) but by default those four methods do not delegate to the request context: Done() returns nil, so a select on c.Done() blocks forever and passing c straight into db.QueryContext produces a query that can never be cancelled.

Setting engine.ContextWithFallback = true makes them fall through to c.Request.Context(). Also worth knowing: c.FullPath() returns the matched route pattern (/users/:id) rather than the concrete URL, which is exactly what you want as a metric or span label, and it returns an empty string on a 404 because no tree node matched.

r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id")                  // path param
    page := c.DefaultQuery("page", "1")  // ?page=
    uid := c.GetString("user_id")        // set by auth mw; "" if absent
    route := c.FullPath()                // "/users/:id", safe metric label

    // WRONG unless engine.ContextWithFallback = true:
    //   c.Done() is nil, so this query is never cancelled
    //   rows, err := db.QueryContext(c, ...)
    rows, err := db.QueryContext(c.Request.Context(),
        "SELECT id, name FROM users WHERE id = $1", id)
    if err != nil {
        c.AbortWithStatusJSON(500, gin.H{"error": "db"})
        return
    }
    defer rows.Close()

    c.JSON(200, gin.H{"id": id, "page": page, "route": route, "caller": uid})
})

Answer

Define a Go struct with json tags and (optionally) binding tags, then call c.ShouldBindJSON(&dst). Gin reads the body, unmarshals JSON, and runs validator.v10 on the binding tags. Use ShouldBindJSON over the older BindJSON, the latter automatically writes a 400 response on failure, which breaks any handler that wants to format its own error envelope.

Always check the returned error and return early. Concretely, c.Bind/c.BindJSON call MustBindWith, which on failure runs c.AbortWithError(400, err) and writes a text/plain body, so the response is already committed and your JSON envelope turns into a 'http: superfluous response.WriteHeader call' warning in the log. Failure modes worth naming in an interview: an empty body returns io.EOF rather than a validation error, so handle that case separately if the endpoint tolerates no body; unknown JSON fields are silently discarded unless you set binding.EnableDecoderDisallowUnknownFields = true once at startup; and large integers lose precision through float64 unless you set binding.EnableDecoderUseNumber = true or declare the field as json.Number.

Distinguishing absent from zero matters on PATCH endpoints, because {"active":false} and {} both bind to false on a bool field, so use *bool or *int when the difference is meaningful. Finally, ShouldBindJSON will read an unbounded body into memory, so cap it before binding with c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 1<<20) and map the resulting 'http: request body too large' error to 413 rather than a generic 400.

type CreateUser struct {
    Email string `json:"email" binding:"required,email"`
    Age   int    `json:"age" binding:"required,gte=18,lte=120"`
}

r.POST("/users", func(c *gin.Context) {
    var in CreateUser
    if err := c.ShouldBindJSON(&in); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }
    c.JSON(201, gin.H{"created": in})
})

Answer

Three distinct binding paths: c.ShouldBindQuery for ?a=1&b=2 query strings, c.ShouldBind (auto-detects from Content-Type) for application/x-www-form-urlencoded or multipart, and c.ShouldBindUri for path parameters declared as :name. Each uses a different struct tag, `form:"a"` for query/form, `uri:"id"` for path. For one-off reads without a struct, c.Query("a") and c.PostForm("b") work too.

The struct-binding form is preferred for anything more than two fields because validator.v10 runs only on tags. The dispatch rule inside c.ShouldBind is worth memorising: for GET it always uses the form binder (query string), and for other verbs it switches on Content-Type, application/json to the JSON binder, application/xml to XML, multipart/form-data to the multipart binder, and anything else to form. A POST that forgets its Content-Type header therefore silently gets form-decoded and every field comes back empty, which is the single most common 'my binding returns zeros' bug.

The default= modifier in a form tag only fires when the key is absent, not when it is present but empty, so ?page= binds to 0 and then fails your gte=1 rule rather than falling back to 1. Use c.GetQuery("x") when you genuinely need to tell absent from empty, since it returns (value, bool). Repeated keys need c.QueryArray("tag") or a []string field, and bracketed keys like filter[status]=open need c.QueryMap("filter").

Time fields require an explicit tag, `form:"from" time_format:"2006-01-02" time_utc:"1"`, or binding fails with a parsing error. Note also that ShouldBindUri never 404s on its own: an unparseable :id gives you a binding error you must map to 400 or 404 yourself.

type ListReq struct {
    Page    int    `form:"page,default=1" binding:"gte=1"`
    PerPage int    `form:"per_page,default=20" binding:"gte=1,lte=100"`
    Sort    string `form:"sort" binding:"oneof=asc desc"`
}

type ItemURI struct {
    ID int `uri:"id" binding:"required,gt=0"`
}

r.GET("/items/:id", func(c *gin.Context) {
    var u ItemURI
    if err := c.ShouldBindUri(&u); err != nil { c.JSON(400, gin.H{"err": err.Error()}); return }
    var q ListReq
    if err := c.ShouldBindQuery(&q); err != nil { c.JSON(400, gin.H{"err": err.Error()}); return }
    // ...
})

Answer

Middleware in Gin is just a func(*gin.Context), same signature as a handler. Register it with Use() on the engine (applies globally), on a RouterGroup (applies to all routes in the group), or in the handler list of a single route. Inside, call c.Next() to invoke the next handler in the chain and run code after it returns, or c.Abort() to short-circuit. gin.Default() pre-wires Logger and Recovery; in production you typically add auth, request-ID, CORS, GZIP, and tracing middleware on top.

The mechanism explains the two classic bugs. Gin does not evaluate middleware dynamically: when you register a route, the group's current handler slice is combined with the route's handlers into one flat slice stored on the tree node. So an r.Use(Auth()) placed after r.GET("/admin", h) does not protect that route at all, it only applies to routes registered later.

Order of registration is order of execution, which is why Recovery goes first (it must wrap everything, including your logger), then request-ID, then logging, then CORS, then auth, then rate limiting. The second bug is length: the combined slice is walked by an int8 index and Gin panics with 'too many handlers' beyond 63 per route, so deeply nested groups each adding four or five middlewares can genuinely hit the ceiling. Also remember that anything you want to run after the handler must sit below c.Next() and should be guarded by c.IsAborted() if it assumes the handler ran, and if the post-Next work must run even when a downstream handler panics, put it in a defer rather than after the Next call.

func RequestID() gin.HandlerFunc {
    return func(c *gin.Context) {
        id := uuid.NewString()
        c.Set("req_id", id)
        c.Writer.Header().Set("X-Request-ID", id)
        c.Next() // run subsequent handlers
        // code here runs AFTER the handler
    }
}

r := gin.Default()
r.Use(RequestID())

authed := r.Group("/api", AuthRequired())
authed.GET("/me", meHandler)

Answer

Use r.Static("/assets", "./public") to mount a directory under a URL prefix, r.StaticFile("/favicon.ico", "./favicon.ico") for a single file, and r.StaticFS for a custom http.FileSystem (useful with embed.FS in Go 1.16+). For HTML, call r.LoadHTMLGlob("templates/*.html") at startup and render with c.HTML(200, "index.html", gin.H{...}). In production, you'd usually offload static serving to nginx or a CDN, r.Static is convenient but not optimised for high-fanout asset delivery.

Under the hood r.Static registers a catch-all route backed by http.FileServer, which means two things: you get Range requests, ETag and If-Modified-Since handling for free through http.ServeContent, and you also get automatic directory listings for any folder without an index.html. If that is not what you want, serve through StaticFS with a http.FileSystem wrapper whose Open returns os.ErrNotExist for directories. On the template side, LoadHTMLGlob parses everything once at boot, so editing a template in dev needs a restart, and any parse error panics at startup rather than at render time.

Template names are the base filenames, so templates/admin/index.html and templates/user/index.html collide unless you use LoadHTMLFiles with distinct define blocks. r.SetFuncMap must be called before the load call or your custom functions are not visible to the parser. With embed.FS the usual trap is the directory prefix: http.FS(assets) serves /assets/app.css as /assets/assets/app.css, so wrap it with fs.Sub(assets, "assets") first. Rendering a name that does not exist panics inside c.HTML and surfaces as a 500 through Recovery, so a smoke test that hits every template route is cheap insurance.

//go:embed templates/* assets/*
var assets embed.FS

r := gin.Default()
r.SetHTMLTemplate(template.Must(template.ParseFS(assets, "templates/*.html")))
r.StaticFS("/assets", http.FS(assets))
r.GET("/", func(c *gin.Context) {
    c.HTML(200, "index.html", gin.H{"title": "Home"})
})

Answer

Single-file uploads use c.FormFile("field") which returns a *multipart.FileHeader, then c.SaveUploadedFile(file, dst) to persist. For multiple files use c.MultipartForm(). Set the engine's MaxMultipartMemory (default 32 MiB) to bound how much is buffered in RAM before spilling to disk.

For streaming uploads larger than ~50 MiB, open the file with hdr.Open() and io.Copy into the destination yourself instead of using SaveUploadedFile. What actually happens: c.FormFile calls c.Request.ParseMultipartForm(MaxMultipartMemory), which buffers up to that many bytes in RAM and spills the remainder to temporary files in os.TempDir(), cleaned up when the request ends. MaxMultipartMemory therefore bounds RAM per request, not upload size, so ten concurrent 32 MiB uploads is still 320 MiB of heap.

The real ceiling has to come from c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 20<<20), which makes the parse fail with 'http: request body too large' that you map to 413. Never trust the client-supplied Content-Type on the part header; sniff the first 512 bytes with http.DetectContentType and compare against an allowlist, because a .jpg upload can be a polyglot HTML file that becomes stored XSS when you serve it from your own origin. For multi-file forms, c.MultipartForm() returns *multipart.Form and you should defer form.RemoveAll() to drop the temp files early. If you are shipping to object storage, skip the disk entirely: f, _ := hdr.Open(); defer f.Close(); then stream f into the S3 uploader so a 2 GB upload never touches the pod's ephemeral volume.

r.MaxMultipartMemory = 8 << 20 // 8 MiB

r.POST("/upload", func(c *gin.Context) {
    file, err := c.FormFile("file")
    if err != nil { c.JSON(400, gin.H{"error": err.Error()}); return }
    if err := c.SaveUploadedFile(file, "./uploads/"+file.Filename); err != nil {
        c.JSON(500, gin.H{"error": err.Error()}); return
    }
    c.JSON(200, gin.H{"filename": file.Filename, "size": file.Size})
})

Answer

Gin provides typed helpers on *gin.Context: c.JSON(code, obj), c.XML, c.YAML, c.ProtoBuf, c.String(code, format, args...), c.Data(code, mime, bytes) for raw bytes, c.Redirect(code, url), and c.Status(code) when you'll write the body manually. c.AbortWithStatusJSON(code, obj) is a common shortcut from middleware, it writes the response AND prevents downstream handlers from running. Once you've written headers (via Status or any of the writers), you cannot change them, Gin's Writer wraps http.ResponseWriter and tracks Written() to enforce this. Writing twice logs 'http: superfluous response.WriteHeader call' with the offending file and line, which is the fingerprint of a missing return after an Abort.

The JSON family has more members than people expect and the differences are interview-worthy: c.JSON escapes <, > and & into \u003c style sequences (safe when the payload is inlined into HTML), c.PureJSON leaves them literal, c.AsciiJSON escapes all non-ASCII, c.IndentedJSON is for humans only because it roughly doubles bytes and CPU, and c.SecureJSON prefixes top-level arrays with while(1); to defeat legacy JSON hijacking. For downloads, c.File(path) streams via http.ServeFile with Range support, while c.FileAttachment(path, name) additionally sets Content-Disposition; that filename was not properly escaped before Gin v1.9.1 (CVE-2023-29401), so a crafted name could inject response headers, which is a good reason to state your Gin version when asked about it. c.Redirect must be called before anything is written and rejects codes outside the 3xx range apart from 201. When you need full control, c.Status(code) followed by writes to c.Writer works, and c.Writer.Flush() plus the http.Flusher interface is how you push bytes early for streaming responses.

r.POST("/items", func(c *gin.Context) {
    if !authorized(c) {
        c.AbortWithStatusJSON(401, gin.H{"error": "unauthorized"})
        return
    }
    c.JSON(201, gin.H{"id": 42})
})

Answer

gin.New() returns an Engine with NO middleware attached. gin.Default() returns the same Engine but pre-registered with two middlewares: gin.Logger() (writes a one-line access log per request to os.Stdout) and gin.Recovery() (recovers from any panic in a handler and returns 500 instead of crashing the server). For production, most teams use gin.New() and add their own structured logger (zerolog, zap) and a customised recovery middleware that reports to Sentry / OTel. The default Logger uses fmt.Fprintf to stdout, fine for dev, slow and unstructured for production.

Two behaviours of the bundled middleware are worth knowing before you replace them. gin.Logger() writes to gin.DefaultWriter (an io.Writer you can point at a file or an io.MultiWriter) and gin.LoggerWithConfig lets you pass SkipPaths, which every real service uses to keep /healthz and /metrics out of the log stream; without it a 1-second Kubernetes probe interval alone produces 86,400 useless lines a day per pod. gin.Recovery() is smarter than a bare recover(): it inspects the panic value for a net.OpError wrapping a syscall error of 'broken pipe' or 'connection reset by peer' and in that case logs and aborts without attempting to write a 500, because the client socket is already gone and writing would panic again. It also prints the request dump and a filtered stack trace to gin.DefaultErrorWriter. The practical production stack is gin.New() plus your own recovery built on gin.CustomRecovery (so panics reach Sentry or OTel), your own slog/zap request logger with SkipPaths, and no reliance on Gin's console output at all. Whichever you choose, Recovery must be registered first so it wraps every other middleware.

// dev
r := gin.Default() // == gin.New() + Logger() + Recovery()

// production
r := gin.New()
r.Use(gin.CustomRecovery(reportPanic))        // first: wraps everything below
r.Use(RequestID(), StructuredLogger(logger))  // your own, structured
r.Use(gin.LoggerWithConfig(gin.LoggerConfig{  // only if you keep Gin's logger
    Output:    os.Stdout,
    SkipPaths: []string{"/healthz", "/readyz", "/metrics"},
}))

Answer

Use r.Group("/prefix", middleware...) to create a RouterGroup. Routes registered on the group inherit the prefix and all middleware passed when the group was created. Groups can be nested, and each nested group adds to the middleware chain.

This is the cleanest way to apply versioning (/v1, /v2), authentication scope (public vs authenticated), or feature areas. Mechanically, Group returns a new *RouterGroup holding a copy of the parent's handler slice plus whatever you passed, and group.BasePath() tells you the accumulated prefix. Because that copy is taken at Group() time and combined again at route-registration time, calling group.Use() after the group's routes are registered affects nothing, the same trap as on the engine.

The braces you see in most examples are plain Go blocks with no semantics at all; they exist only so the routes indent under their group, and dropping them changes nothing. Practical rules interviewers like: keep two sibling groups on the same prefix rather than one group with per-route exceptions, so /api/v1 public (login, signup, webhooks) and /api/v1 authed (everything else) are visibly separate and nobody accidentally registers a login route behind the auth middleware. Attach middleware to the narrowest scope that needs it, since a rate limiter or a body-size cap on the engine also applies to your health check.

And when only one route needs an extra guard, pass it inline as authed.DELETE("/users/:id", AdminOnly(), deleteUser) instead of creating a group of one. For versioning, register v2 as its own group with its own handlers rather than branching on a header inside shared handlers, which keeps route listings and traces honest.

r := gin.Default()

public := r.Group("/api/v1")
{
    public.POST("/login", login)
    public.POST("/signup", signup)
}

auth := r.Group("/api/v1", AuthRequired())
{
    auth.GET("/me", me)
    admin := auth.Group("/admin", AdminOnly())
    admin.DELETE("/users/:id", deleteUser)
}

Answer

Gin uses a fork of httprouter that stores routes in a radix tree (compact trie). Each segment of the URL path is a node; common prefixes are merged. At request time, the tree walks character-by-character from the root, branching on static segments, :param captures, and *wildcard tails.

The walk is O(length of path) and allocation-free in the common case, which is why Gin's routing benchmark is on the same order as raw net/http. Conflict rules: you cannot register both a static segment and a :param at the same depth (e.g. /users/me and /users/:id will panic at registration), but Gin v1.10 relaxed this in some cases via the UseRawPath / UnescapePathValues options. Knowing this comes up in interviews because newcomers from Express/Flask often expect first-match wins.

State the current behaviour precisely, because a sharp interviewer will know it: today's Gin tree backtracks, so a static sibling and a param at the same depth do coexist, /users/me and /users/:id both register and the static segment wins the match. What still panics at startup is two different parameter names in the same position, a catch-all colliding with existing children, or a catch-all that is not the final segment, with a message shaped like "':userID' in new path '/users/:userID/roles' conflicts with existing wildcard ':id'". Gin also keeps one tree per HTTP method (the methodTrees slice), which is why a path registered only for GET answers a POST with 404 rather than 405 until you set r.HandleMethodNotAllowed = true, at which point Gin scans the sibling trees and returns 405 with an Allow header.

Encoded slashes are the other sharp edge: matching runs on the already-unescaped URL.Path, so /files/a%2Fb arrives as two segments, and you need r.UseRawPath = true with r.UnescapePathValues = false when a path parameter can legitimately contain %2F. The matched node is also what backs c.FullPath(), which is why reading it costs nothing and why it is the correct label for metrics and spans.

r := gin.New()
r.GET("/users/me", meHandler)    // static and param siblings coexist;
r.GET("/users/:id", getUser)     // "/users/me" wins over ":id"
r.GET("/files/*path", serveFile) // catch-all must be the last segment

// PANICS at startup: same position, different param name
// r.GET("/users/:userID/roles", roles)
//   -> ':userID' in new path conflicts with existing wildcard ':id'

r.HandleMethodNotAllowed = true // 405 + Allow header instead of 404
r.UseRawPath = true             // match against the escaped path
r.UnescapePathValues = false    // c.Param keeps %2F intact

for _, ri := range r.Routes() { // startup sanity check
    log.Printf("%-6s %-24s %s", ri.Method, ri.Path, ri.Handler)
}

Answer

Gin has three modes selected by gin.SetMode(gin.DebugMode | gin.ReleaseMode | gin.TestMode) or by the GIN_MODE environment variable, which the package reads in its init function. Debug is the default and it does real work: it prints the whole route table as [GIN-debug] lines at registration, prints a warning every time you use a feature it considers unsafe by default, and emits the banner '[WARNING] Running in "debug" mode. Switch to "release" mode in production.' on every boot.

Release silences all of that and skips the debug-only branches inside the router and the HTML renderer. TestMode is what you set in TestMain so the test output is not drowned in route dumps. Three practical points.

SetMode must run before you build the engine and register routes, otherwise the debug prints have already happened; it panics on any string other than the three known values, so wiring it straight to a free-form env var is a boot-time crash waiting to happen. gin.DisableConsoleColor() matters in containers, because the default Logger writes ANSI colour codes that turn into escape garbage in Loki or CloudWatch. And gin.DebugPrintRouteFunc lets you redirect the route table into your structured logger instead of stdout, which is a nice startup artefact to keep even in release builds.

func main() {
    // GIN_MODE is read at package init; SetMode overrides it
    if os.Getenv("APP_ENV") == "production" {
        gin.SetMode(gin.ReleaseMode) // no [GIN-debug] lines, no warning banner
    }
    gin.DisableConsoleColor() // no ANSI escapes in container logs

    gin.DebugPrintRouteFunc = func(method, path, handler string, n int) {
        slog.Info("route", "method", method, "path", path, "handlers", n)
    }

    r := gin.New()
    // ... register routes AFTER SetMode
}

func TestMain(m *testing.M) {
    gin.SetMode(gin.TestMode)
    os.Exit(m.Run())
}

Answer

r.NoRoute(h) registers the handler used when no route matches the path, and r.NoMethod(h) the handler used when the path exists but not for that HTTP verb. The catch is that NoMethod never fires unless you also set r.HandleMethodNotAllowed = true, which is false by default; until you do, a POST to a GET-only endpoint returns 404, and API gateways or SDKs that branch on 405 behave incorrectly. When the flag is on, Gin scans the other per-method trees, sets the Allow header for you and calls your NoMethod chain.

Scope is the other thing interviewers probe: NoRoute handlers run the engine-level middleware (so request-ID, logging and tracing still cover them) but not group middleware, because no group matched, which means a 404 under /api/v1 is not authenticated and should not leak whether a resource exists. Inside NoRoute, c.FullPath() is empty and c.Request.URL.Path is the only thing you have, so log the raw path but be careful about echoing it back into a JSON body unescaped. The common production shape is a content-negotiated fallback: JSON errors for /api prefixes, and index.html for everything else when the same binary serves a single-page app. Do not blanket-return index.html, or every mistyped API path answers 200 with HTML and your client fails while parsing.

r.HandleMethodNotAllowed = true // otherwise NoMethod never runs

r.NoRoute(func(c *gin.Context) {
    if strings.HasPrefix(c.Request.URL.Path, "/api/") {
        c.JSON(404, gin.H{"error": "not_found", "path": c.Request.URL.Path})
        return
    }
    c.File("./dist/index.html") // SPA fallback for non-API paths only
})

r.NoMethod(func(c *gin.Context) {
    // Gin already filled Allow from the sibling method trees
    c.JSON(405, gin.H{
        "error": "method_not_allowed",
        "allow": c.Writer.Header().Get("Allow"),
    })
})

Answer

c.Next() invokes the rest of the handler chain and returns when it completes, code after Next() runs as a 'response phase' after the actual handler. c.Abort() prevents any handlers registered AFTER the current point in the chain from running, but it does NOT stop execution of the current middleware, you still need to return early. A common bug: writing `c.AbortWithStatusJSON(401, ...)` without a `return` afterwards, then continuing to access state that may not be initialised. Another subtle one: Abort affects only the chain, not the goroutine, so spawned goroutines keep running.

The pattern is: validate at the top of middleware, call AbortWithStatusJSON on failure, return; otherwise call c.Next() at the bottom (or leave it implicit if you have nothing to do post-handler). The implementation makes this concrete. Context carries an int8 index into the flat handler slice; Next() increments it in a loop and calls each handler, while Abort() sets the index to abortIndex (63, which is math.MaxInt8/2) so the loop terminates.

Three consequences fall out of that. Abort writes nothing on its own, it only stops the chain, so a bare c.Abort() produces a 200 with an empty body unless something already wrote; use AbortWithStatus or AbortWithStatusJSON. Code after your c.Next() still runs when a downstream handler aborted, so guard it with c.IsAborted() if it assumes the handler executed.

And because 63 is a hard ceiling, Gin panics with 'too many handlers' when nested groups pile up middleware, which surfaces at startup rather than under load. One more thing seniors check: if a downstream handler panics, the statements after your c.Next() are skipped entirely, so latency metrics and log lines written inline are lost on exactly the requests you most want to see. Put that work in a defer at the top of the middleware instead, then Recovery converts the panic to a 500 and your defer still records it.

func AuthRequired() gin.HandlerFunc {
    return func(c *gin.Context) {
        token := c.GetHeader("Authorization")
        userID, err := verifyJWT(token)
        if err != nil {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
            return // CRUCIAL, Abort does not return for you
        }
        c.Set("user_id", userID)
        c.Next()
        // code here runs after the handler, log, metric, etc.
        log.Printf("req status=%d user=%d", c.Writer.Status(), userID)
    }
}

Answer

*gin.Context is allocated from an internal sync.Pool. As soon as the handler returns, Gin resets the context and returns it to the pool, the same struct will be reused for the next incoming request. If you spawn a goroutine inside a handler and pass the live *gin.Context, you have a race: the goroutine may read fields that have already been overwritten by another request, or write to a Writer that points to a different connection. c.Copy() returns a copy that's safe for read in goroutines, it carries the keys, the request, and the Errors slice but explicitly nils out the Writer (so you can't accidentally write a response to the wrong client).

This is one of the most common Gin bugs in code review. Precisely what Copy gives you: a new Context with the Keys map and Params slice copied, the same *http.Request pointer, a writer whose ResponseWriter is nil, and index set to abortIndex so calling Next on the copy is a no-op. Note the Request pointer is shared, not deep-copied, so reading c.Copy().Request.Body in a goroutine still races with the server closing it after the handler returns; snapshot any body bytes before you spawn.

The trap that catches people even after they add Copy is cancellation: since Go 1.20 net/http cancels the request context as soon as ServeHTTP returns, so a goroutine holding c.Request.Context() sees context.Canceled a microsecond after you respond, and the audit write or webhook you fired off silently fails with 'context canceled' while your handler reports 202. The fixes are context.WithoutCancel(c.Request.Context()) from Go 1.21 when you only want to keep the trace and baggage values, or a fresh context.WithTimeout(context.Background(), …) with the trace span carried over explicitly. Better still for anything durable, do not spawn at all: write to an outbox table or a queue and let a worker consume it, because an unbounded 'go' per request is also how a traffic spike turns into an OOMKill. Run go test -race in CI; the race detector catches the pooled-context reuse reliably.

r.POST("/order", func(c *gin.Context) {
    var in Order
    if err := c.ShouldBindJSON(&in); err != nil { c.JSON(400, gin.H{"err": err.Error()}); return }

    ctx := c.Copy() // safe to pass into goroutines
    go func() {
        // long-running audit log; ctx is a snapshot
        reqID, _ := ctx.Get("req_id")
        auditLog(ctx.Request.Context(), in, reqID)
    }()

    c.JSON(202, gin.H{"queued": true})
})

Answer

gin.Recovery() (included in gin.Default()) installs a deferred recover() in the middleware chain. If any downstream handler panics, Recovery catches it, logs the stack to os.Stderr, and writes a 500 to the client. For production you almost always want a custom variant: gin.CustomRecovery(handler) lets you pass a function that receives the *gin.Context and the recovered value.

That's where you wire structured logging (zap.Error, slog), error reporting (Sentry, Honeybadger), and tracing (OTel span.RecordError). Two gotchas: (1) Recovery only catches panics in the same goroutine, a panic in a goroutine you spawned crashes the entire process, so wrap those in your own defer/recover; (2) once a response has been partly written, Recovery cannot 'rewrite' it as a 500, it can only log and return. Beyond that, Recovery must be the first middleware registered or it does not cover the middlewares above it, and it deliberately special-cases a dead client: it unwraps net.OpError and os.SyscallError looking for 'broken pipe' or 'connection reset by peer', and in that case logs the error and calls c.Abort() without writing a status, since writing to a closed socket would panic again.

Two panic values also behave unusually. panic(http.ErrAbortHandler) is understood by net/http as a deliberate abort: the connection is closed and no stack trace is logged, which is how proxy code kills a hijacked connection. And a nil map write or nil pointer dereference inside a deferred function of your own runs after Recovery's defer in some orderings, so keep defers simple. In production, wire the recovery handler to emit a structured log with the request ID, record the error on the active OTel span, increment a panics_total counter so it can page you, and return a generic body: the recovered value can contain SQL text or credentials and must never be echoed to the client. Test the path by registering a /debug/panic route behind an internal-only guard in staging.

import "go.uber.org/zap"

r := gin.New()
r.Use(gin.CustomRecovery(func(c *gin.Context, recovered any) {
    logger.Error("panic",
        zap.Any("recovered", recovered),
        zap.String("path", c.FullPath()),
        zap.String("req_id", c.GetString("req_id")),
    )
    sentry.CaptureException(fmt.Errorf("%v", recovered))
    c.AbortWithStatusJSON(500, gin.H{"error": "internal error", "req_id": c.GetString("req_id")})
}))

Answer

Gin uses go-playground/validator/v10 for binding tags. The built-in vocabulary (required, email, gte, oneof, …) covers most needs, but business rules need custom tags. Access the underlying *validator.Validate via binding.Validator.Engine(), then call RegisterValidation("tag", fn).

The function receives a validator.FieldLevel and returns a bool. For richer validation that depends on multiple fields, register a struct-level validation with RegisterStructValidation. In production, register validators once in main() at startup, the engine is goroutine-safe for reads but registering during a request is a race.

A few mechanics that separate a confident answer from a vague one. binding.Validator is a lazily initialised defaultValidator guarded by sync.Once, so the type assertion to *validator.Validate works before any request has been served, and validator caches parsed struct tags per type, meaning the reflection cost is paid once per struct rather than per request. A custom rule that must also run on empty or nil values needs RegisterValidation("tag", fn, true), because the fourth argument callValidationEvenIfNull defaults to false and your rule is skipped on the zero value. Types that are not plain scalars, decimal.Decimal, sql.NullString, uuid.UUID, need RegisterCustomTypeFunc so the validator sees the underlying value instead of a struct.

Cross-field rules come in two flavours: the declarative ones (eqfield, gtfield, required_if, required_unless, excluded_with) cover most cases without any Go code, and RegisterStructValidation with sl.ReportError handles the rest, for example 'discount is only allowed when plan is annual'. Collections need dive to descend, so `binding:"required,dive,email"` validates each element of a []string and `dive,keys,alphanum,endkeys,required` validates map keys. Keep validation to shape and syntax; anything that needs a database lookup belongs in the service layer, not in a validator tag.

import (
    "github.com/gin-gonic/gin/binding"
    "github.com/go-playground/validator/v10"
)

var pinRegex = regexp.MustCompile(`^[1-9][0-9]{5}$`)

func indianPin(fl validator.FieldLevel) bool {
    return pinRegex.MatchString(fl.Field().String())
}

func init() {
    if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
        v.RegisterValidation("indian_pin", indianPin)
    }
}

type Address struct {
    Pin string `json:"pin" binding:"required,indian_pin"`
}

Answer

Every request has a context.Context accessible via c.Request.Context(). It cancels automatically when the client disconnects (TCP close, HTTP/2 stream reset) or the server shuts down. ALWAYS pass that context, never context.Background(), to downstream calls: database queries (db.QueryContext, pgx), HTTP calls (http.NewRequestWithContext), Redis (rdb.Get(ctx, …)), gRPC.

This way a slow query is automatically cancelled when the user gives up. If you add a deadline of your own, use context.WithTimeout(c.Request.Context(), 2*time.Second) so cancellation still propagates. The classic mistake is `go doWork(c)` which neither cancels with the request nor is safe (see the c.Copy question).

The second classic mistake is passing c itself where a context.Context is expected. It compiles, because *gin.Context implements the interface, but with the default engine settings its Done() returns nil and its Deadline() reports no deadline, so the query you thought was cancellable runs to completion on the database long after the client hung up. Either always write c.Request.Context() or set engine.ContextWithFallback = true so the Gin context delegates.

Getting this right shows up directly in incidents: when a load balancer times out at 30 seconds and clients retry, uncancelled Postgres queries pile up until the pool is exhausted and healthy endpoints start failing too. On the response side, distinguish the two error cases. context.DeadlineExceeded is your own timeout and should map to 504, while context.Canceled usually means the client went away, in which case writing a 500 pollutes your error rate: log it at info and use a non-standard 499 or simply stop writing. Use errors.Is rather than string matching, and note that drivers surface it differently, pq reports 'pq: canceling statement due to user request' and pgx wraps the context error. Since Go 1.20 you can also attach a reason with context.WithCancelCause and read it back through context.Cause(ctx).

r.GET("/users/:id", func(c *gin.Context) {
    ctx, cancel := context.WithTimeout(c.Request.Context(), 500*time.Millisecond)
    defer cancel()

    var u User
    err := db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE id = $1", c.Param("id")).Scan(&u.ID, &u.Name)
    if errors.Is(err, context.DeadlineExceeded) {
        c.AbortWithStatusJSON(504, gin.H{"error": "upstream slow"})
        return
    }
    if err != nil { c.AbortWithStatusJSON(500, gin.H{"error": err.Error()}); return }
    c.JSON(200, u)
})

Answer

Standard pattern: a /login endpoint validates credentials and signs a JWT with a short TTL (15-30 minutes); a middleware extracts the token from the Authorization header, verifies the signature, parses claims, and stores the user ID on c via c.Set. Protected routes read it back with c.MustGet. Use github.com/golang-jwt/jwt/v5 (the maintained fork), the old dgrijalva/jwt-go is unmaintained and has CVEs.

The signing secret lives in env vars / a secret manager, never in source. For refresh tokens, store them as HttpOnly, Secure, SameSite=Lax cookies to limit XSS exposure. In v5 the idiomatic defence against algorithm confusion is not a hand-written check inside the keyfunc but the parser option jwt.WithValidMethods([]string{"HS256"}), which rejects a token whose header claims none or RS256 before the key function is even consulted; add jwt.WithLeeway(30*time.Second) for clock skew across pods and jwt.WithIssuer / jwt.WithAudience so you cannot accept a token minted for a different service.

Prefer jwt.ParseWithClaims with your own struct embedding jwt.RegisteredClaims over MapClaims, because the map version forces you to type-assert every field and a claim that arrives as a float64 instead of a string is a runtime panic in production. Design points an interviewer will push on: JWTs cannot be revoked, so pair short access tokens with a jti denylist in Redis expiring at the token's exp, and rotate refresh tokens on every use so a stolen one is detectable. Use RS256 or EdDSA with a JWKS endpoint once more than one service verifies tokens, caching the key set and honouring kid so rotation does not require a redeploy.

Keep PII out of claims, since the payload is base64, not encrypted. Finally, return 401 for a missing or invalid token and 403 for a valid token without the required scope; conflating them makes client retry logic wrong.

import "github.com/golang-jwt/jwt/v5"

func AuthRequired(secret []byte) gin.HandlerFunc {
    return func(c *gin.Context) {
        h := c.GetHeader("Authorization")
        if !strings.HasPrefix(h, "Bearer ") {
            c.AbortWithStatusJSON(401, gin.H{"error": "missing token"}); return
        }
        tok, err := jwt.Parse(h[7:], func(t *jwt.Token) (any, error) {
            if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
                return nil, fmt.Errorf("bad alg")
            }
            return secret, nil
        })
        if err != nil || !tok.Valid {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"}); return
        }
        claims := tok.Claims.(jwt.MapClaims)
        c.Set("user_id", claims["sub"])
        c.Next()
    }
}

Answer

r.Run() blocks and offers no shutdown hook, wrap your engine in an http.Server instead, call srv.ListenAndServe() in a goroutine, listen for SIGINT/SIGTERM with signal.NotifyContext, and on signal call srv.Shutdown(ctx) with a deadline. Shutdown stops accepting new connections and waits for in-flight requests to finish up to the deadline. This is critical in Kubernetes: when a pod is terminated, K8s sends SIGTERM and then SIGKILL after terminationGracePeriodSeconds (30 s default).

Without graceful shutdown you drop in-flight requests on every rolling deploy. Add a /healthz handler that flips to 'draining' on SIGTERM so the load balancer stops sending you traffic during the grace period. The ordering is where candidates lose marks, because Shutdown alone still drops requests.

Kubernetes removes the pod from Endpoints and sends SIGTERM concurrently, and kube-proxy or the ingress can take several seconds to stop routing, so the correct sequence is: flip readiness to failing, sleep 5 to 10 seconds (or use a preStop hook that does the sleep), then call srv.Shutdown, then close the database pool, flush the OTel tracer provider and the log buffer, and only then exit. Set terminationGracePeriodSeconds comfortably above your shutdown deadline or the kubelet sends SIGKILL mid-drain. Know the limits of Shutdown too: it closes idle keep-alive connections and waits for active ones, but it does not touch hijacked connections, so WebSocket and SSE handlers need your own registry plus srv.RegisterOnShutdown to signal them, otherwise Shutdown blocks until the context deadline every single deploy.

Long-poll endpoints have the same problem. srv.Close is the hard version and cuts everything immediately; keep it as the fallback after the graceful deadline expires. Also make in-flight work idempotent, since a request that was accepted and then killed at the deadline will be retried by the client.

func main() {
    r := gin.New()
    // ... routes
    srv := &http.Server{Addr: ":8080", Handler: r, ReadHeaderTimeout: 5 * time.Second}

    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    go func() {
        if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
            log.Fatalf("listen: %v", err)
        }
    }()
    <-ctx.Done()
    log.Println("shutting down")

    shutdownCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
    defer cancel()
    if err := srv.Shutdown(shutdownCtx); err != nil {
        log.Fatalf("forced shutdown: %v", err)
    }
}

Answer

Gin handlers can be tested with httptest.NewRecorder + r.ServeHTTP, no real socket needed. Set gin.SetMode(gin.TestMode) at the top of TestMain to silence logs. Build the engine the same way main() does, but with mocked dependencies injected (use functional options or a constructor that takes interfaces).

For end-to-end tests, httptest.NewServer(r) gives a real TCP listener so external clients (e.g. a Go SDK consumer) can hit the URL. Table-driven tests are idiomatic and let you cover happy-path, validation errors, auth failures, and edge cases in one function. Details that make the difference between tests that pass and tests that mean something.

Always set Content-Type on the request: without it, c.ShouldBind falls back to the form binder and every field arrives empty, so your 'validation works' test passes for the wrong reason. Build the engine through the same constructor main() uses, because a test router assembled by hand skips the middleware order that causes real bugs. Assert on the decoded body, not on the raw string, since key order in a map-backed response is not stable. httptest.NewRequest fills RemoteAddr with 192.0.2.1:1234, which matters the moment you test an IP-keyed rate limiter or c.ClientIP().

For middleware in isolation, gin.CreateTestContext(w) returns a Context with no Request attached, so set c.Request yourself or the first c.GetHeader call nil-pointers. Keep table cases small and cover the four families interviewers ask about: happy path, binding and validation failures, authentication and authorisation failures, and dependency errors injected through a fake. Above that, use testcontainers-go to run a real Postgres or Redis for repository tests rather than mocking SQL, and run the whole suite with -race in CI, because Gin's pooled contexts and shared middleware state are exactly what the race detector is good at catching.

func TestCreateUser(t *testing.T) {
    gin.SetMode(gin.TestMode)
    r := newRouter(&fakeStore{})

    cases := []struct{ name, body string; want int }{
        {"ok", `{"email":"a@b.c","age":30}`, 201},
        {"missing email", `{"age":30}`, 400},
        {"underage", `{"email":"a@b.c","age":12}`, 400},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            w := httptest.NewRecorder()
            req := httptest.NewRequest("POST", "/users", strings.NewReader(tc.body))
            req.Header.Set("Content-Type", "application/json")
            r.ServeHTTP(w, req)
            if w.Code != tc.want { t.Fatalf("got %d want %d", w.Code, tc.want) }
        })
    }
}

Answer

All five are viable in 2026, the choice is about ergonomics and ecosystem more than raw speed. net/http stdlib (with Go 1.22's improved ServeMux supporting method + path params) is the lowest-dependency option, great for tiny services and library code. Chi is a thin router-only library that composes well with stdlib middleware and is the go-to for teams that want net/http compatibility. Gin is the most popular full-feature framework, large community, plenty of middleware (gin-contrib/*), familiar to most Go devs in India.

Echo is similar in scope to Gin with a slightly cleaner API and stronger built-in middleware (rate-limit, JWT) but a smaller community. Fiber wraps fasthttp instead of net/http, about 1.3-2× faster in micro-benchmarks but incompatible with the standard ecosystem (no http.Handler, separate context type), and you lose HTTP/2 and HTTP/3 support since fasthttp doesn't have first-class support. Rule of thumb: Gin for general microservices, Chi for stdlib-friendly libraries, Echo if you prefer its API, Fiber only when fasthttp's tradeoffs are acceptable.

Be concrete about what Go 1.22 actually changed, since interviewers use it as a probe: http.ServeMux now understands method and wildcard patterns, so mux.HandleFunc("GET /items/{id}", h) works and r.PathValue("id") reads the segment, with precedence going to the most specific pattern instead of panicking on conflicts. What stdlib still does not give you is binding plus validation, a rendering layer, grouping, or a middleware chain with an abort mechanism, which is roughly the 300 lines of glue every team writes before deciding a framework was fine. The other axis is migration cost.

Gin, Echo and Chi all sit on net/http, so moving between them is a mechanical rewrite of handler signatures and your middleware keeps working; moving to or from Fiber is not, because fasthttp has its own request and response types and no http.Handler compatibility, which quietly rules out any library that expects one. Contract-first teams should also weigh OpenAPI support: with Gin you generate specs from comments using swaggo, whereas Huma or Fuego derive the spec from typed handlers, and Huma can run on top of Gin if you want both.

Answer

Replace gin.Logger() with a middleware that emits one structured event per request. Capture status, method, path (use c.FullPath() to get the route pattern, not the raw URL, better cardinality for metrics), latency, request ID, user ID, and any errors via c.Errors. Go 1.21+ ships log/slog in the stdlib, which is good enough for many services; high-volume services usually pick zap (Uber, fastest) or zerolog (smallest allocations).

Always log AFTER c.Next() so you have the final status code. Avoid logging request bodies wholesale, they leak PII; log a hash or selected fields instead. Why FullPath matters concretely: logging c.Request.URL.Path turns /users/91827 into a distinct label value, and a million users become a million series in Loki or Prometheus, which is how a logging change takes down the observability stack rather than the app.

Correlation is the other half of the job. Pull trace_id and span_id out of the active span with trace.SpanContextFromContext(c.Request.Context()) and put them on every line, so a log search jumps straight to the trace; propagate the incoming X-Request-ID header when present instead of always minting a new one, or the ID breaks at each hop. Set the level from the status class (5xx error, 4xx warn, everything else info) and attach c.Errors.String() only when non-empty.

Cost is real at scale: gin.Logger's fmt.Fprintf path allocates and formats on every request, zap's SugaredLogger is a few hundred nanoseconds and zerolog's zero-allocation builder less, and a 10k RPS pod writing one 400-byte line per request produces roughly 350 GB a day, which is why you sample 2xx access logs and keep 100 percent of 5xx. Redact before logging with an allowlist of fields, never a denylist, and treat Authorization headers, phone numbers and PAN or Aadhaar-style identifiers as never-loggable.

import "log/slog"

func StructuredLogger(logger *slog.Logger) gin.HandlerFunc {
    return func(c *gin.Context) {
        start := time.Now()
        c.Next()
        logger.LogAttrs(c.Request.Context(), slog.LevelInfo, "http_request",
            slog.String("method", c.Request.Method),
            slog.String("route", c.FullPath()),
            slog.Int("status", c.Writer.Status()),
            slog.Duration("latency", time.Since(start)),
            slog.String("req_id", c.GetString("req_id")),
            slog.String("errors", c.Errors.String()),
        )
    }
}

Answer

Gin's *gin.Context has an Errors []*Error slice you append to via c.Error(err). The error stays attached to the context throughout the chain, your logging middleware can read it via c.Errors after c.Next(). c.Error returns the *Error so you can chain .SetType(gin.ErrorTypePublic) to mark it as safe to expose. Idiomatic pattern: handlers attach all encountered errors via c.Error, then call AbortWithStatus or return a structured envelope; a single trailing middleware turns the accumulated errors into the response shape.

This avoids the 'every handler formats its own error JSON' duplication and gives you one place to redact internal details. Specifics worth knowing: c.Error panics if you hand it a nil error, so never write c.Error(err) without checking err first. The Type field is a bitmask (ErrorTypeBind, ErrorTypeRender, ErrorTypePublic, ErrorTypePrivate, ErrorTypeAny), and c.Errors.ByType(gin.ErrorTypePublic) filters the slice, which is how a trailing middleware decides what is safe to serialise versus what only goes to the log. c.Errors.Last() gives the most recent, and c.Errors.JSON() renders one object or an array depending on count, so it is convenient but not a stable API shape to expose to clients. c.AbortWithError(code, err) is exactly AbortWithStatus plus Error, and note it also writes the status, so do not follow it with your own c.JSON.

The pattern that scales is to keep domain errors as sentinels or typed errors in the service layer (ErrNotFound, ErrConflict, a ValidationError carrying field details), attach the raw error with c.Error for the logs, and let one error-mapping middleware translate with errors.As and errors.Is into the wire format, including a machine-readable code, the request ID, and field-level details for 422. That way the internal message, which may contain a query or a customer email, never reaches the client, and every service in the fleet returns the same envelope.

// In a handler
if err := svc.Charge(ctx, in); err != nil {
    c.Error(err).SetType(gin.ErrorTypePrivate) // internal
    c.AbortWithStatusJSON(500, gin.H{"error": "charge failed", "req_id": c.GetString("req_id")})
    return
}

// In a trailing logging middleware
c.Next()
for _, e := range c.Errors {
    logger.Error("req error", "err", e.Err, "type", e.Type)
}

Answer

Use github.com/gin-contrib/cors, battle-tested and configurable. Pass an explicit list of origins; never combine AllowAllOrigins=true with AllowCredentials=true (browsers reject the combo). Set MaxAge to cache preflight (OPTIONS) responses for a few hours, without it, every cross-origin request is preceded by a preflight roundtrip.

Common mistake: omitting the methods/headers actually used by the client (e.g. Authorization, X-Request-ID), the browser will silently block. Test by curling with -H 'Origin: https://app.example.com' and inspecting Access-Control-Allow-* response headers. The failure everyone hits at least once is ordering: the browser sends the preflight as OPTIONS without an Authorization header, so if your auth middleware is registered before the CORS middleware the preflight gets a 401 and Chrome reports 'Response to preflight request doesn't pass access control check', which looks like a CORS bug but is an ordering bug.

Register CORS above auth, and make sure nothing else (rate limiter, tenant resolver) rejects OPTIONS either. Remember when a preflight even happens: simple GET or POST with text/plain, form-urlencoded or multipart bodies and no custom headers skip it, but application/json or any custom header triggers one, so a single X-Request-ID from the client doubles your request count until MaxAge caches the answer, and browsers cap that anyway (Chrome at 2 hours regardless of what you send). Emit Vary: Origin whenever the allowed origin is computed per request, otherwise a shared cache or CDN serves one tenant's Access-Control-Allow-Origin to another.

AllowOriginFunc handles dynamic subdomains, but anchor the match on the full host, since a naive strings.Contains(origin, "example.com") also accepts example.com.attacker.io. Finally, be clear that CORS is a browser policy, not authorisation: curl and server-to-server calls ignore it entirely, so it never substitutes for a real authz check.

import "github.com/gin-contrib/cors"

r.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://app.example.com"},
    AllowMethods:     []string{"GET", "POST", "PUT", "DELETE"},
    AllowHeaders:     []string{"Authorization", "Content-Type", "X-Request-ID"},
    ExposeHeaders:    []string{"X-Request-ID"},
    AllowCredentials: true,
    MaxAge:           12 * time.Hour,
}))

Answer

Use the official otelgin contrib middleware (go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin). It extracts the W3C traceparent header from the incoming request, creates a span per request, records HTTP attributes (method, route, status), and propagates the span into c.Request.Context(). Downstream calls (sql, redis, http.Client) that themselves use OTel instrumentation will become child spans automatically.

Always use c.FullPath() (the route pattern) as the span name instead of the raw URL, otherwise you blow up cardinality. Combine with a metric middleware to emit RED (Rate/Errors/Duration) signals to Prometheus, and ship to Tempo/Jaeger/SigNoz. In production at Indian fintechs like Razorpay and PhonePe, this exact stack (Gin + otelgin + Prometheus + Tempo) is standard for transaction tracing across microservices.

The setup step people forget is the propagator: the SDK's default is a no-op composite, so unless you call otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.Baggage{})) at startup, otelgin parses no incoming traceparent and every service starts a fresh trace, giving you a pile of disconnected single-span traces that look like instrumentation is working. Second, otelgin stores the span in c.Request.Context(), so any code that reads c or context.Background() instead gets a span-less context and its children float away; this is the reason to prefer c.Request.Context() everywhere. Use otelgin.WithSpanNameFormatter when you need a name other than the route, and WithFilter to drop health and metrics endpoints, which otherwise dominate your span volume and your bill.

Configure the resource with service.name, service.version and deployment.environment or the backend cannot build a service map. Prefer the batch span processor over the simple one in production, since the simple processor exports synchronously and adds its latency to the request. Finally, keep traces and logs joined by writing trace_id into every log line, and set the sampler once at the root service with parent-based sampling downstream so a sampled request stays sampled through the whole chain.

import (
    "go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin"
    "go.opentelemetry.io/otel"
)

r := gin.New()
r.Use(otelgin.Middleware("payments-api", otelgin.WithFilter(func(req *http.Request) bool {
    return req.URL.Path != "/healthz" // don't trace health checks
})))

r.GET("/orders/:id", func(c *gin.Context) {
    ctx, span := otel.Tracer("payments-api").Start(c.Request.Context(), "loadOrder")
    defer span.End()
    // ... db call with ctx is now a child span
})

Answer

In validator.v10, required means 'not the zero value for this type', not 'present in the payload'. False is the zero value of bool, so `binding:"required"` on Active bool rejects {"active":false} with 'Field validation for Active failed on the required tag', and the same happens for 0 on numbers, the empty string, and empty slices or maps. Pick the fix by intent.

If the field is simply optional, drop required and use omitempty so the remaining rules only run when a value is present. If you must distinguish 'client sent false' from 'client sent nothing', which is the entire point of a PATCH endpoint, make it a pointer: *bool is nil when the key is absent and points at false when it was sent, and required on a pointer only rejects nil. If zero is out of range rather than missing, say a quantity, use gte=1, which also produces a far better error message than required.

Conditional rules cover the rest: required_if, required_unless, required_with, required_without and excluded_with, for example `binding:"required_if=Plan annual"`. Two related traps. required on a nested struct value never fails, because a struct is never nil, so validate the inner fields or make it a pointer. And validator does not descend into slices or maps at all without dive, so it takes `binding:"omitempty,dive,required"` to reject a tags array containing an empty string.

type UpdatePrefs struct {
    // WRONG: {"marketing":false} is rejected as "required"
    // Marketing bool `json:"marketing" binding:"required"`

    Marketing *bool    `json:"marketing"`                 // nil = not sent
    Quantity  int      `json:"quantity" binding:"gte=1"`  // not "required"
    Plan      string   `json:"plan" binding:"oneof=monthly annual"`
    Coupon    string   `json:"coupon" binding:"required_if=Plan annual"`
    Tags      []string `json:"tags" binding:"omitempty,dive,required"`
}

func patchPrefs(c *gin.Context) {
    var in UpdatePrefs
    if err := c.ShouldBindJSON(&in); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }
    if in.Marketing != nil { // only update what the client actually sent
        store.SetMarketing(c.Request.Context(), *in.Marketing)
    }
    c.Status(204)
}

Answer

c.Request.Body is a one-shot io.ReadCloser over the connection, so the first ShouldBindJSON drains it and the next call returns io.EOF. The symptom in production is a handler that binds an empty struct because some middleware already read the body. Three correct fixes.

Use c.ShouldBindBodyWith(&dst, binding.JSON), which reads the body once, caches the bytes on the context under BodyBytesKey and re-reads from that copy on every later call; Gin v1.10 added the typed shorthands ShouldBindBodyWithJSON, ShouldBindBodyWithXML, ShouldBindBodyWithYAML and ShouldBindBodyWithTOML. Or buffer it yourself with io.ReadAll and refill with c.Request.Body = io.NopCloser(bytes.NewReader(raw)), which is what middleware needs when it has to hash or audit the payload before handlers run. Or bind once and pass the struct down, which is the right answer surprisingly often.

Two cautions: all of these hold the entire body in memory, so wrap with http.MaxBytesReader first and never apply them to uploads or streaming endpoints. Webhook signature verification is the case that forces your hand: Razorpay, Stripe and GitHub all sign the exact bytes, so you must compute the HMAC over the buffered copy before any unmarshalling, because re-marshalling the parsed struct changes key order and whitespace and the digest will never match.

func VerifyWebhook(secret []byte) gin.HandlerFunc {
    return func(c *gin.Context) {
        c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 1<<20)
        raw, err := io.ReadAll(c.Request.Body)
        if err != nil {
            c.AbortWithStatusJSON(413, gin.H{"error": "body too large"})
            return
        }
        c.Request.Body = io.NopCloser(bytes.NewReader(raw)) // refill for handlers

        mac := hmac.New(sha256.New, secret)
        mac.Write(raw) // sign the RAW bytes, never the re-marshalled struct
        want := hex.EncodeToString(mac.Sum(nil))
        if !hmac.Equal([]byte(want), []byte(c.GetHeader("X-Signature"))) {
            c.AbortWithStatusJSON(401, gin.H{"error": "bad signature"})
            return
        }
        c.Next()
    }
}

// Handler side: safe to bind repeatedly
var evt Event
if err := c.ShouldBindBodyWith(&evt, binding.JSON); err != nil { /* ... */ }

Answer

The error returned by ShouldBindJSON is not one error. For rule failures it is a validator.ValidationErrors, a slice of FieldError, and calling err.Error() on it produces the notorious "Key: 'CreateUser.Email' Error:Field validation for 'Email' failed on the 'email' tag" string, which leaks Go struct names and is useless to a form UI. Unwrap it with errors.As(err, &ve), then read fe.Field() for the field, fe.Tag() for the rule that failed, fe.Param() for the rule's argument (8 in min=8) and fe.Value() for what was sent, and map tags to messages through one table so wording stays consistent across the service.

By default fe.Field() is the Go name, so call RegisterTagNameFunc once at startup to report the json name the client actually sent. Handle the non-validation branches separately, because they mean different things: a *json.SyntaxError is malformed JSON, a *json.UnmarshalTypeError is a wrong type for a known field (it carries Field and Type so you can report both), io.EOF is an empty body, and the MaxBytesReader error is an oversized one. The convention most teams settle on is 422 with a details array for rule failures and 400 for anything unparseable, both carrying the request ID so support can find the log line. validator also integrates with go-playground/universal-translator if you need localised messages.

func init() { // report json names instead of Go field names
    if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
        v.RegisterTagNameFunc(func(f reflect.StructField) string {
            name := strings.Split(f.Tag.Get("json"), ",")[0]
            if name == "-" { return "" }
            return name
        })
    }
}

var msgs = map[string]string{
    "required": "this field is required",
    "email":    "must be a valid email address",
    "gte":      "must be at least %s",
    "oneof":    "must be one of: %s",
}

func bindError(c *gin.Context, err error) {
    var ve validator.ValidationErrors
    if errors.As(err, &ve) {
        out := make([]gin.H, 0, len(ve))
        for _, fe := range ve {
            m, ok := msgs[fe.Tag()]
            if !ok { m = "failed rule " + fe.Tag() }
            out = append(out, gin.H{
                "field":   fe.Field(),
                "rule":    fe.Tag(),
                "message": strings.Replace(m, "%s", fe.Param(), 1),
            })
        }
        c.AbortWithStatusJSON(422, gin.H{"errors": out})
        return
    }
    c.AbortWithStatusJSON(400, gin.H{"error": "malformed request body"})
}

Answer

Gin gives you two entry points: c.Stream(func(w io.Writer) bool) loops while your function returns true and flushes after each iteration, and c.SSEvent(name, data) writes a correctly framed event. Gin's ResponseWriter implements http.Flusher, and c.Stream also stops when the client disconnects. Making it actually stream end to end means defeating every buffer in the path.

Set Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive and X-Accel-Buffering: no so nginx forwards each chunk instead of accumulating. Exclude the route from any gzip middleware, because the compressor holds bytes until its window fills and your events arrive in bursts. Set WriteTimeout to 0 for streaming routes, or use http.ResponseController.SetWriteDeadline from Go 1.20 to extend it per write, otherwise the connection dies exactly at the timeout.

Then the operational details: EventSource reconnects automatically, so emit an id: field and honour Last-Event-ID or clients replay the stream from the beginning; send a comment heartbeat every 15 to 30 seconds because idle load balancers close silent connections (AWS ALB defaults to 60 seconds); and remember srv.Shutdown waits for these long-lived connections, so track them and close them when draining or every deploy stalls until the shutdown deadline. For bidirectional traffic use WebSockets instead, but note that hijacking the connection takes the request outside Gin's middleware chain, so your logger, Recovery and tracing no longer see it.

r.GET("/events", func(c *gin.Context) {
    h := c.Writer.Header()
    h.Set("Content-Type", "text/event-stream")
    h.Set("Cache-Control", "no-cache")
    h.Set("Connection", "keep-alive")
    h.Set("X-Accel-Buffering", "no") // nginx must not buffer

    ch := bus.Subscribe(c.Request.Context())
    beat := time.NewTicker(20 * time.Second)
    defer beat.Stop()

    c.Stream(func(w io.Writer) bool {
        select {
        case <-c.Request.Context().Done():
            return false // client went away
        case ev, ok := <-ch:
            if !ok { return false }
            c.SSEvent("message", ev) // id/event/data framing, then flush
            return true
        case <-beat.C:
            fmt.Fprint(w, ": ping\n\n") // comment keeps proxies open
            return true
        }
    })
})

Answer

gin.CreateTestContext(w) returns a (*gin.Context, *gin.Engine) pair bound to your httptest.ResponseRecorder, letting you invoke a middleware directly without routing. The catch is what it does not set up. The context has no Request, so the first c.GetHeader, c.ClientIP or c.ShouldBindJSON dereferences nil; assign c.Request = httptest.NewRequest(...) yourself.

Its handler chain is empty, so c.Next() returns immediately and you cannot prove 'the handler did not run' that way; assert on c.IsAborted() and the recorder's Code instead. Nothing matched a route, so c.Params must be set by hand as gin.Params{{Key: "id", Value: "42"}} and c.FullPath() stays empty, which will bite any middleware that uses FullPath as a metric label. What is worth asserting: status and body on the reject path, that IsAborted is true, the values the middleware stored (checked with c.Get, not c.MustGet, so a failure is an assertion rather than a panic), and headers written to the recorder.

Anything that depends on ordering, interaction between middlewares, or route matching should instead go through a full engine built by your production constructor and driven with r.ServeHTTP, because CreateTestContext bypasses exactly those parts. Keep both: the isolated test for the branch matrix (missing header, malformed token, expired token, wrong algorithm) and one integration test proving the middleware is actually registered on the routes you believe it is.

func TestAuthRequired_RejectsMissingToken(t *testing.T) {
    gin.SetMode(gin.TestMode)
    w := httptest.NewRecorder()
    c, _ := gin.CreateTestContext(w)
    c.Request = httptest.NewRequest("GET", "/me", nil) // REQUIRED: else nil deref
    c.Params = gin.Params{{Key: "id", Value: "42"}}    // no route matched

    AuthRequired([]byte("secret"))(c)

    if !c.IsAborted() { t.Fatal("expected the chain to abort") }
    if w.Code != 401 { t.Fatalf("status = %d, want 401", w.Code) }
    if _, ok := c.Get("user_id"); ok { t.Fatal("user_id must not be set") }
}

// Integration: proves the middleware is really wired to the route
func TestMeRouteIsProtected(t *testing.T) {
    r := newRouter(&fakeStore{}) // same constructor main() uses
    w := httptest.NewRecorder()
    r.ServeHTTP(w, httptest.NewRequest("GET", "/api/v1/me", nil))
    if w.Code != 401 { t.Fatalf("status = %d, want 401", w.Code) }
}

Answer

The wins, in order of impact: (1) Use gin.New() (no default Logger/Recovery) and replace both with allocation-free alternatives, the default Logger calls fmt.Fprintf which is slow at high RPS; use zerolog with sampling or skip access logs entirely and rely on traces. (2) Tune the underlying http.Server: ReadHeaderTimeout (mandatory, defends against Slowloris), IdleTimeout for keep-alive, and increase MaxHeaderBytes only if needed. (3) Connection pools sized properly, database pool size = 4-8× CPU cores per instance, Redis with a pool, share one *http.Client/transport across all upstream calls. (4) Use json-iterator/go or goccy/go-json when JSON payloads are large, both are ~2-4× faster than encoding/json; Gin natively supports json-iterator via the jsoniter build tag. (5) Reuse buffers via sync.Pool in hot paths (CSV exports, large response composition). (6) GOGC/GOMEMLIMIT (Go 1.19+), for steady-state services, GOGC=200 reduces CPU at the cost of slightly more RAM, GOMEMLIMIT prevents OOMKills. (7) Profile with pprof (gin-contrib/pprof) under load, typical bottlenecks are JSON marshalling, reflect-heavy validation, and lock contention in your own code. (8) Horizontally scale behind a layer-4 LB (nginx, HAProxy, GCP L4 ILB), Gin saturates a single 8-core box around 100-150k RPS for trivial JSON.

srv := &http.Server{
    Addr:              ":8080",
    Handler:           r,
    ReadHeaderTimeout: 5 * time.Second,  // mandatory: Slowloris defence
    ReadTimeout:       15 * time.Second,
    WriteTimeout:      30 * time.Second, // must be 0 on streaming routes
    IdleTimeout:       90 * time.Second, // keep above the LB idle timeout
    MaxHeaderBytes:    1 << 20,
}

n := runtime.GOMAXPROCS(0)
db.SetMaxOpenConns(8 * n)
db.SetMaxIdleConns(8 * n) // idle == open avoids reconnect churn
db.SetConnMaxLifetime(30 * time.Minute)

// ONE shared client per upstream; never http.Get inside a handler
var upstream = &http.Client{
    Timeout: 2 * time.Second,
    Transport: &http.Transport{
        MaxIdleConnsPerHost: 100, // default is 2 and throttles fan-out hard
        IdleConnTimeout:     90 * time.Second,
    },
}

// container env: GOMEMLIMIT=900MiB GOGC=200
// profile under real load, do not guess:
//   go tool pprof -http=: http://127.0.0.1:6060/debug/pprof/profile?seconds=30

Answer

Three patterns, pick by tenant count and regulatory needs: (1) Row-level (tenant_id column on every table). Extract tenant_id from a verified JWT claim in middleware, c.Set("tenant_id", id), and use a Repository or query builder that ALWAYS injects the predicate. Belt-and-braces: add a static-analysis test that fails CI if any query references a tenant-scoped table without tenant_id; in Postgres add Row-Level Security policies bound to a SET LOCAL app.tenant_id = … set inside the connection. (2) Schema-per-tenant on Postgres, switch via SET search_path in a per-request hook.

Best isolation, harder operations as tenants grow to thousands. (3) DB-per-tenant, full isolation, needed for some regulated industries (Indian banking, healthcare under HIPAA-equivalent rules), expensive at scale. Cross-cutting: ALWAYS source tenant_id from a signed token, never from a request header or body, trusting client-supplied tenant IDs is the most common multi-tenant breach. Add a tenant_id label to every metric, every trace span, and every log line, when an incident happens you'll want to slice by tenant immediately.

For rate limiting, key by (tenant_id, user_id, route) so a noisy tenant can't starve others. Two operational points separate a real design from a whiteboard one. Schema-per-tenant and database-per-tenant multiply connections: 500 tenants with a 10-connection pool each exhausts Postgres long before you run out of CPU, so put PgBouncer in transaction mode in front and pool per shard rather than per tenant. And prove the isolation in CI: a test that authenticates as tenant A and walks every tenant-scoped endpoint asking for tenant B's IDs, asserting 404 rather than 403, because a 403 already confirms the resource exists.

// Request-scoped transaction with the tenant pinned for Postgres RLS.
func TenantScope(db *sql.DB) gin.HandlerFunc {
    return func(c *gin.Context) {
        tid := c.GetString("tenant_id") // from the VERIFIED JWT, never a header
        if tid == "" {
            c.AbortWithStatusJSON(401, gin.H{"error": "no tenant"})
            return
        }
        ctx := c.Request.Context()
        tx, err := db.BeginTx(ctx, nil)
        if err != nil {
            c.AbortWithStatusJSON(503, gin.H{"error": "db"})
            return
        }
        // set_config(..., true) is transaction-local, so it cannot leak
        // to the next request that reuses this pooled connection
        if _, err := tx.ExecContext(ctx,
            "SELECT set_config('app.tenant_id', $1, true)", tid); err != nil {
            tx.Rollback()
            c.AbortWithStatusJSON(503, gin.H{"error": "db"})
            return
        }
        c.Set("tx", tx)
        c.Next()
        if c.Writer.Status() >= 400 || c.IsAborted() {
            tx.Rollback()
            return
        }
        tx.Commit()
    }
}

// ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
// CREATE POLICY tenant_isolation ON invoices
//   USING (tenant_id = current_setting('app.tenant_id')::uuid);

Answer

Every Gin handler runs in its own goroutine, there's no per-request locking by default. Shared state must be protected. (1) For per-request scratch buffers (encoding/decoding, response composition), use sync.Pool, Get one at the top of the handler, Reset it, defer pool.Put back. This is how Gin itself pools *gin.Context.

Don't keep references past the handler. (2) For maps shared across requests where reads dominate (config, route metadata), use sync.Map; for write-heavy maps, an RWMutex around a regular map is usually faster, sync.Map's two-store design has overhead for write-heavy patterns. (3) For counters/gauges, atomic.Int64 (Go 1.19+) is allocation-free and faster than mutex-protected ints. (4) For initialisation, sync.Once is the right primitive, avoid the 'check then lock' anti-pattern. (5) NEVER share a *gin.Context, a *sql.Rows, or a database transaction across goroutines, they're not safe even with locks. (6) Detect races early with `go test -race` in CI and -race builds in staging. Two more patterns come up constantly in Gin services. Use golang.org/x/sync/singleflight around expensive cache misses so a hot key expiring under load produces one database query instead of a thundering herd of 500 identical ones.

And when a handler fans out to several upstreams, use errgroup.WithContext plus g.SetLimit(n) rather than bare go statements, so failures cancel siblings, the wait is structured, and concurrency is bounded; an unbounded goroutine per request is a memory leak with a traffic spike as its trigger. Also be precise about sync.Pool semantics in an interview: it is a cache, not a free list with guarantees, its contents are cleared at every GC cycle, and putting a slice back after it has grown to megabytes keeps that memory alive, so check capacity before Put. Objects taken from a pool must be reset before use, since Gin itself does exactly that with each recycled Context.

var jsonBuf = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func bigResponse(c *gin.Context) {
    buf := jsonBuf.Get().(*bytes.Buffer)
    buf.Reset()
    defer jsonBuf.Put(buf)

    enc := json.NewEncoder(buf)
    // ... build response in buf
    c.Data(200, "application/json", buf.Bytes())
}

Answer

In-process counters (golang.org/x/time/rate) don't work across N instances, each instance has its own bucket and a client effectively gets N× the limit. The standard solution is a Redis-backed limiter. Two algorithms: (1) Fixed window with INCR + EXPIRE, simplest, atomic in a Lua script, but suffers from boundary bursts (2× the limit can pass at window edges). (2) Sliding-window counter via sorted sets (ZADD timestamp, ZREMRANGEBYSCORE older than window, ZCARD), accurate, slightly more Redis work.

Use a Lua script to make the whole check atomic; otherwise two concurrent requests can both observe count < limit and both pass. Key design: limit per (api_key OR user_id OR IP) and per route group; combine multiple buckets ('60 req/min global + 10 req/sec burst') with the strictest winning. Always set sensible defaults: 60 rpm per IP for unauthenticated, 600 rpm per user authenticated, then bump for trusted clients.

On Redis failure, fail open (allow) for non-critical APIs but fail closed (deny) for write paths to a payment system, the right answer depends on business risk. In India, Razorpay and PhonePe both run multi-tier limiters: edge (Cloudflare) for crude IP bans, service-level (Redis) for per-merchant quotas, plus per-route circuit breakers.

// Lua script (atomic): KEY[1]=bucket, ARGV[1]=limit, ARGV[2]=window_secs
const rateLua = `
local current = redis.call('INCR', KEYS[1])
if current == 1 then redis.call('EXPIRE', KEYS[1], ARGV[2]) end
if current > tonumber(ARGV[1]) then return 0 end
return 1`

func RateLimit(rdb *redis.Client, limit int, window time.Duration) gin.HandlerFunc {
    script := redis.NewScript(rateLua)
    return func(c *gin.Context) {
        key := "rl:" + c.ClientIP() + ":" + c.FullPath()
        ok, err := script.Run(c.Request.Context(), rdb, []string{key}, limit, int(window.Seconds())).Int()
        if err != nil { c.Next(); return } // fail open
        if ok == 0 {
            c.AbortWithStatusJSON(429, gin.H{"error": "rate limit"}); return
        }
        c.Next()
    }
}

Answer

Use OpenTelemetry end-to-end. Architecture: (1) Each Gin service wires otelgin as inbound middleware, it parses the W3C traceparent header and roots a span per request. (2) Every outgoing call must be instrumented to inject the traceparent header. For http.Client wrap the Transport with otelhttp.NewTransport; for database/sql use otelsql; for Redis use redisotel.InstrumentTracing; for gRPC the otelgrpc interceptor.

Without these, the trace is broken at the boundary. (3) Always pass c.Request.Context() into every call, that context carries the active span. (4) Use semantic attributes (semconv), http.route, http.status_code, db.system, peer.service, so observability backends can build service maps. (5) Sampling: use parent-based + ratio (1-5% of root requests) in steady state; bump to 100% for error traces via tail-based sampling at the OTel Collector. (6) Export via OTLP to a backend like SigNoz (used in-house here at GoodSpace), Tempo, Honeycomb, or Datadog. (7) Cross-cutting context: stuff tenant_id, user_id, and req_id into baggage so they propagate end-to-end without re-extraction. (8) Critical gotcha: spans created inside goroutines must use the right ctx, if you c.Copy() and pass into a goroutine, the goroutine should start a new span as child of c.Copy().Request.Context() (which carries the parent span). Don't reuse the parent span across goroutines or you'll get incorrect timings and concurrent End() calls.

Answer

ContextWithFallback is a boolean field on *gin.Engine, added in Gin v1.8.1 and still false by default for backwards compatibility. *gin.Context implements context.Context, but with the flag off those four methods are stubs: Deadline() reports no deadline, Done() returns nil, Err() returns nil, and Value() only consults Gin's own Keys map. Three failures follow directly, and all of them compile cleanly. First, a receive on a nil channel blocks forever, so any select on c.Done() waiting for the client to disconnect never fires.

Second, passing c where a context.Context is expected disables cancellation: db.QueryContext(c, q) keeps running on the database after the caller has gone, and http.NewRequestWithContext(c, ...) inherits no deadline, which is how one slow upstream drains the connection pool. Third, values placed in the request context by middleware are invisible, so otel.SpanFromContext(c) hands back a no-op span, your child spans detach from the trace, and instrumentation libraries that stash a transaction or a logger in the context silently get nothing. Setting r.ContextWithFallback = true makes all four delegate to c.Request.Context() when it is non-nil, which is what most engineers assume already happens.

Enable it on new services. On an existing one, expect background work that used to run forever to start getting cancelled, which is a latent bug surfacing rather than a regression. The habit that survives either setting is to write c.Request.Context() explicitly at every call site.

r := gin.New()
r.ContextWithFallback = true // Gin v1.8.1+, default false

r.GET("/report", func(c *gin.Context) {
    // With the flag OFF all three of these are quietly broken:
    //   <-c.Done()             // nil channel, blocks forever
    //   db.QueryContext(c, q)  // never cancelled when the client leaves
    //   otel.SpanFromContext(c) // no-op span, the trace detaches here
    // With it ON they behave like c.Request.Context().

    ctx, cancel := context.WithTimeout(c, 3*time.Second)
    defer cancel()

    rows, err := db.QueryContext(ctx, "SELECT id FROM ledger WHERE day = $1", day)
    switch {
    case errors.Is(err, context.Canceled):
        c.Abort() // client hung up: log at info, do not count it as a 5xx
        return
    case errors.Is(err, context.DeadlineExceeded):
        c.AbortWithStatusJSON(504, gin.H{"error": "report timed out"})
        return
    case err != nil:
        c.AbortWithStatusJSON(500, gin.H{"error": "db"})
        return
    }
    defer rows.Close()
    c.JSON(200, collect(rows))
})

Answer

c.ClientIP() is not the socket address. The resolution order is: if Engine.TrustedPlatform is set (gin.PlatformCloudflare reads CF-Connecting-IP, gin.PlatformGoogleAppEngine reads X-Appengine-Remote-Addr, or you supply your own header name) that header wins outright; otherwise, if ForwardedByClientIP is true (the default) and the immediate peer is inside the trusted proxy set, Gin walks the headers in RemoteIPHeaders (X-Forwarded-For then X-Real-IP by default) from right to left and returns the right-most address that is not itself a trusted proxy; if nothing qualifies it falls back to the host part of RemoteAddr. SetTrustedProxies(cidrs) defines that trusted set, and the default trusts everything, which is why Gin prints a startup warning telling you to narrow it.

The consequence of leaving it wide open is that any client can assert X-Forwarded-For: 1.2.3.4 and become that address, defeating IP rate limiting, allowlists, geo rules and audit trails in one line of curl; the related X-Forwarded-Prefix handling issue was fixed as CVE-2023-26125 in v1.9.0. Configure the real CIDRs of your ingress, or call SetTrustedProxies(nil) plus TrustedPlatform when exactly one CDN always fronts you. In Kubernetes, count the hops (a cloud LB plus an ingress appends two entries), and note that with externalTrafficPolicy: Cluster the source IP is SNATed to a node address before Gin sees anything, so no header setting recovers the true client.

r := gin.New()

// A: behind your own ingress or LB, trust only its ranges
if err := r.SetTrustedProxies([]string{"10.0.0.0/8", "172.16.0.0/12"}); err != nil {
    log.Fatalf("trusted proxies: %v", err)
}

// B: always behind one CDN
// r.SetTrustedProxies(nil)
// r.TrustedPlatform = gin.PlatformCloudflare // uses CF-Connecting-IP

// C: no proxy at all, ignore forwarding headers entirely
// r.ForwardedByClientIP = false

r.GET("/whoami", func(c *gin.Context) {
    c.JSON(200, gin.H{
        "client_ip": c.ClientIP(), // resolved through the rules above
        "remote_ip": c.RemoteIP(), // raw peer address
        "xff":       c.GetHeader("X-Forwarded-For"),
    })
})

// Prove the config holds before shipping an IP-based rate limiter:
//   curl -H 'X-Forwarded-For: 1.2.3.4' http://localhost:8080/whoami

Answer

Expose net/http/pprof on an internal-only listener (a plain http.ListenAndServe on 127.0.0.1:6060 in a goroutine, or gin-contrib/pprof registered behind an internal guard) and never on the public router. Then work from the symptom rather than guessing. For goroutines, take /debug/pprof/goroutine?debug=1 twice several minutes apart and diff them: the counts are grouped by stack, so a stack that keeps climbing names the leak outright, and ?debug=2 gives full stacks with how long each has been blocked.

The Gin-specific causes repeat: an unbounded go statement per request; a goroutine blocked sending on a channel nobody reads once the client disconnected; a select on c.Done() with ContextWithFallback off, which waits on a nil channel forever; upstream response bodies never Closed, which pins a goroutine and a connection each; and time.Tick or an unstopped Ticker created inside a handler. For memory, snapshot /debug/pprof/heap, wait, snapshot again, and compare with go tool pprof -base, so you see what grew instead of what is merely big. Separate live heap from RSS before declaring a leak, since a high GOGC legitimately leaves RSS well above the live set.

Usual suspects are a process-local cache with no eviction, oversized buffers returned to a sync.Pool, and small slices keeping a huge backing array alive. Prevention: set GOMEMLIMIT, run go test -race in CI, and alert on the go_goroutines gauge instead of finding out during an incident.

// internal-only profiling listener (import _ "net/http/pprof")
go func() {
    log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
}()

// or on the Gin engine, gated:
// if os.Getenv("ENABLE_PPROF") == "1" {
//     pprof.RouteRegister(r.Group("/debug", InternalOnly()), "pprof")
// }

// goroutine leak: diff two snapshots, look for stacks whose count grew
//   curl -s 'localhost:6060/debug/pprof/goroutine?debug=1' > g1.txt
//   sleep 300
//   curl -s 'localhost:6060/debug/pprof/goroutine?debug=1' > g2.txt
//   diff g1.txt g2.txt | head -40
//   curl -s 'localhost:6060/debug/pprof/goroutine?debug=2' | less  # full stacks

// heap growth: compare against a baseline, never eyeball one profile
//   curl -s localhost:6060/debug/pprof/heap > base.pb.gz
//   sleep 900
//   curl -s localhost:6060/debug/pprof/heap > later.pb.gz
//   go tool pprof -base base.pb.gz later.pb.gz