The Architecture

A payment authorization pipeline typically looks like this:

graph LR
    A[Card Network] -->|ISO 8583| B[Parser API]
    B -->|gRPC| C[Distributor API]
    C -->|gRPC| D[Account Service]
    C -->|gRPC| E[Risk Engine]
    C -->|gRPC| F[Ledger]

The rate limiter sits between the Parser API and the Distributor API. It must make a decision in under 1ms.

Warning

Never rate-limit at the card network ingress point. Network protocols like ISO 8583 have strict timeout windows. A delayed response is worse than a fast decline: it triggers a reversal cascade.

Choosing an Algorithm

Token Bucket

The token bucket algorithm maintains a counter that refills at a fixed rate. Each request consumes one token.

Tip

Set C to handle your peak burst (Black Friday spike) and r to your sustained p99 throughput. For authorization systems, measure both per-issuer and per-BIN to avoid penalizing an entire bank for one merchant’s spike.

Sliding Window Log

Tracks the exact timestamp of every request in a time window. Precise, but memory-intensive.

Sliding Window Counter

Token Bucket: O(1) memory, O(1) time, allows bursts. No per-client fairness without separate buckets. Best for global throughput protection.

Sliding Window: Precise rate tracking, smooth distribution. O(n) memory for log variant, interpolation error for counter variant. Best for per-client or per-issuer fairness.

The Distributed Coordination Problem

sequenceDiagram
    participant Client
    participant Region A
    participant Region B
    participant Redis
    Client->>Region A: Auth Request 1
    Client->>Region B: Auth Request 2
    Region A->>Redis: INCR counter
    Region B->>Redis: INCR counter
    Redis-->>Region A: count=1 (allow)
    Redis-->>Region B: count=2 (allow)

The fundamental tension: strong consistency (single Redis) adds a network hop to every authorization, while eventual consistency allows brief over-admission. For payment systems, brief over-admission is almost always preferable to adding latency.

Implementation in Go

type TokenBucket struct {
    mu       sync.Mutex
    tokens   float64
    capacity float64
    rate     float64
    lastTime time.Time
}

func (tb *TokenBucket) Allow() bool {
    tb.mu.Lock()
    defer tb.mu.Unlock()
    now := time.Now()
    elapsed := now.Sub(tb.lastTime).Seconds()
    tb.tokens = math.Min(tb.capacity, tb.tokens+tb.rate*elapsed)
    tb.lastTime = now
    if tb.tokens >= 1 {
        tb.tokens--
        return true
    }
    return false
}

This implementation uses a mutex for simplicity. In production, consider sync/atomic with CAS operations for lock-free performance, or a sharded bucket per goroutine with periodic merging.

Key Takeaways

Design decisions for payment rate limiters:

• Token bucket for global protection, sliding window for per-client fairness
• Local-first with async sync beats centralized coordination for latency
• Set capacity from measured burst patterns, not theoretical maximums
• Monitor rejection rate as a business metric, not just an infra metric

Web API Rate Limiting: Return 429 Too Many Requests. Client retries with backoff. False positives are annoying but recoverable.

Payment Rate Limiting: Return decline response code in ISO 8583. No retry – transaction is failed. False positives are declined cards at checkout.

The difference between rate limiting a REST API and rate limiting an authorization pipeline is the cost of a false positive. In payments, you are not protecting a server – you are deciding whether someone’s groceries get paid for.

What is a Bitmap?

A bitmap is a binary structure where each bit position corresponds to a data element. If bit N is set to 1, data element N is present in the message. If it is 0, the element is absent.

The primary bitmap is always 64 bits (8 bytes). If bit 1 of the primary bitmap is set, a secondary bitmap follows, extending the field range from 65 to 128.

Parsing in Go

The parsing logic is straightforward once you understand the bit layout:

func ParseBitmap(data []byte) (Bitmap, error) {
    if len(data) < 8 {
        return Bitmap{}, fmt.Errorf("bitmap data too short: %d bytes", len(data))
    }

    primary := binary.BigEndian.Uint64(data[:8])
    bm := Bitmap{Primary: primary}

    if primary&(1<<63) != 0 {
        if len(data) < 16 {
            return Bitmap{}, fmt.Errorf("secondary bitmap indicated but data too short")
        }
        bm.Secondary = binary.BigEndian.Uint64(data[8:16])
        bm.HasSecondary = true
    }

    return bm, nil
}

Why This Matters

The elegance of this design is that the message is self-describing. No schema negotiation, no version headers, no content-type declarations. The bitmap IS the schema.

This means a parser can handle any valid ISO 8583 message without knowing in advance which fields will be present. The bitmap tells it exactly what to expect and where to find it.

Key Takeaways

• Primary bitmap: bits 1-64, always present (8 bytes)
• Secondary bitmap: bits 65-128, present only if bit 1 of primary is set
• Each bit maps to one data element by position
• Bit numbering starts at 1, not 0 (bit 1 is the MSB of the first byte)

Always wrap with context that answers “what were you trying to do?” not “what went wrong?” The original error already says what went wrong.

Bad: fmt.Errorf("error: %w", err) Good: fmt.Errorf("parsing field DE%d: %w", fieldNum, err)

What Is LiteLLM?

LiteLLM is a Python library that works like a universal remote for AI APIs. 95 million downloads per month on PyPI. ~40,000 GitHub stars.

The Attack Chain

sequenceDiagram
    participant A as Attacker (TeamPCP)
    participant T as Trivy GitHub Repo
    participant CI as LiteLLM CI (GitHub Actions)
    participant P as PyPI Registry

    Note over A,T: March 1 - Initial Compromise
    A->>T: Submit malicious PR (Pwn Request)
    T-->>A: CI leaks personal access token
    Note over CI,P: March 24 - Package Takeover
    CI->>T: Pull trivy-action@latest (not pinned to SHA)
    T-->>CI: Serve compromised action
    CI-->>A: Leak PyPI publisher token
    A->>P: Publish litellm v1.82.7 (inline payload)
    A->>P: Publish litellm v1.82.8 (.pth persistence)

graph LR
    A["Trivy Repo\n(compromised)"] --> B["GitHub Bot Army"]
    B --> C["PyPI Account Takeover"]
    C --> D["LiteLLM v1.82.7 / v1.82.8"]
    D --> E[".pth Backdoor"]
    E --> F["Credential Harvest"]
    F --> G["Exfil Server (ICP Canister)"]

What the Malware Does

The payload was triple-nested: a base64 blob decodes to an orchestrator script, which decodes a second base64 blob containing the harvester.

graph TD
    ROOT[".pth Backdoor"]
    ROOT --> ENV["ENV Variables"]
    ROOT --> AWS["~/.aws/credentials"]
    ROOT --> DOTENV[".env Files"]
    ROOT --> PROC["/proc/self/environ"]
    ROOT --> EXFIL["Outbound HTTP Exfil to ICP canister"]
    ENV --> EXFIL
    AWS --> EXFIL
    DOTENV --> EXFIL
    PROC --> EXFIL

Two versions were published:

• v1.82.7: injected payload at line 128 of litellm/proxy/proxy_server.py
• v1.82.8: added a .pth file that executes every time Python starts

.pth files in site-packages execute code before your application begins, on every Python invocation: pytest, IDE language server, even pip install.

Check Your Environment

ls ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "litellm_init.pth" 2>/dev/null

If anything shows up, upgrading the package is not enough. Rotate all LLM provider API keys, cloud credentials, GitHub and PyPI tokens, CI/CD secrets, and SSH keys. Rebuild from known-good images. The last known-clean version is 1.82.6.

The Problem with Modular Hashing

If you have 4 nodes and add a 5th, almost every key remaps to a different node. With hash(key) % 4 becoming hash(key) % 5, roughly 80% of your cache is invalidated instantly. Under load, this is a cache stampede.

How Consistent Hashing Works

Consistent hashing arranges the hash space into a ring. Each node is assigned one or more positions on the ring. A key is hashed to a position, and the first node clockwise from that position owns the key.

When a node joins, it takes responsibility for a portion of its neighbor’s range. When a node leaves, its range is absorbed by the next node clockwise. In both cases, only K/N keys need to move, where K is the total number of keys and N is the number of nodes.

Virtual Nodes

Real implementations use virtual nodes – each physical node gets multiple positions on the ring. This smooths out the distribution and prevents hotspots caused by uneven hash space allocation.

Key Takeaways

• Modular hashing invalidates ~(N-1)/N keys on node changes
• Consistent hashing invalidates only ~K/N keys
• Virtual nodes solve the distribution imbalance problem
• Used by DynamoDB, Cassandra, Memcached, and most distributed caches

The API is cleaner, it is part of the standard library (no dependency), and the handler interface makes it trivial to swap backends. The performance gap that once justified zerolog has narrowed significantly.

The Problem

A client sends an authorization request. The network drops the response. The client retries. Without idempotency, the server processes the authorization again, resulting in a double charge.

UUIDs as Idempotency Keys

The client generates a UUID before the first attempt and includes it in every retry. The server checks: have I seen this UUID before? If yes, return the original response. If no, process the request and store the UUID with its response.

Why UUID v7

UUID v7 embeds a Unix timestamp in the first 48 bits, followed by random bits. This gives you:

• Chronological ordering: UUIDs sort by creation time, which makes database indexes efficient
• Uniqueness: the random component prevents collisions even at high throughput
• Expiry: you can garbage-collect old idempotency records by inspecting the embedded timestamp

Key Takeaways

• Idempotency keys prevent duplicate processing in distributed systems
• UUID v7 provides time-ordered uniqueness without coordination
• The embedded timestamp enables efficient cleanup of expired records
• Always generate the idempotency key client-side, never server-side

I ran it again. Same order. Added more input. Still sorted.

At that point, my instincts kicked in. Go maps are unordered. I knew that. So why was the output behaving so politely?

The non-negotiable fact

Go maps do not guarantee iteration order. Ever. The language spec is explicit.

What is actually happening inside a Go map

A Go map is a hash table. Iteration walks buckets in a runtime-defined sequence, not key order.

graph LR
    subgraph "Hash Function"
        H["hash(key)"]
    end
    K1["a"] --> H
    K2["b"] --> H
    K3["m"] --> H
    K4["1"] --> H
    H --> B0["Bucket 0\n1"]
    H --> B1["Bucket 1\n2"]
    H --> B3["Bucket 3\na"]
    H --> B4["Bucket 4\nb"]
    H --> B6["Bucket 6\nm"]

Why the output looked sorted

Small number of keys, short ASCII strings, no map resizing during insertion. Under these conditions, hash values distribute nicely across buckets, and the bucket layout in memory often correlates with lexical order. By coincidence.

graph TD
    S["Small ASCII key set"]
    L["Large / diverse key set"]
    S --> O1["Appears sorted (coincidence)"]
    L --> O2["Visibly unordered (reality)"]

A simplified mental model

Input keys:  a   b   m   x   y   z   1   2   9

Buckets in memory order:
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]
 1   2   9   a   b       m           x    y    z

Iteration walks buckets left to right:
1 2 9 a b m x y z

Digits first. Then letters. Within each group, alphabetical-looking. No sorting happened. Change the input distribution, force collisions, trigger a map resize, and this illusion breaks instantly.

Deterministic-looking behavior does not imply guarantees.

This got me thinking about when we actually need tolerance-based comparisons versus when we’re just cargo-culting best practices.

graph LR
    A["0.1 + 0.2"] --> B["IEEE 754"]
    B --> C["0.30000...04"]
    D["0.3"] --> E["IEEE 754"]
    E --> F["0.29999...99"]
    C --> G["Gap = epsilon"]
    F --> G

When tolerance matters

I was working on a discount calculation system:

func calculateDiscount(price, rate float64) float64 {
    return price * rate
}

func TestDiscountCalculation(t *testing.T) {
    price := 29.99
    rate := 0.15
    expected := 4.4985
    result := calculateDiscount(price, rate)
    if result != expected {
        t.Errorf("got %v, want %v", result, expected)
    }
}

With tolerance, you’d handle it like this:

func almostEqual(a, b, tolerance float64) bool {
    return math.Abs(a-b) <= tolerance
}

func TestDiscountCalculationWithTolerance(t *testing.T) {
    price := 29.99
    rate := 0.15
    expected := 4.4985
    result := calculateDiscount(price, rate)
    if !almostEqual(result, expected, 1e-9) {
        t.Errorf("got %v, want %v", result, expected)
    }
}

When you DON’T need tolerance

Some comparisons are fine without tolerance:

if value == 0.0 { } // Zero has exact representation
if math.IsNaN(result) { } // Special values
if result == math.Inf(1) { } // Infinity comparisons

If your floats haven’t been through different computational paths, exact comparison often works fine.

flowchart TD
    A["Comparing floats?"] --> B{"Result of\narithmetic?"}
    B -- Yes --> C["Use epsilon"]
    B -- No --> D{"Integer-\nconvertible?"}
    D -- Yes --> E["No epsilon needed"]
    D -- No --> F{"Currency?"}
    F -- Yes --> G["Use integer cents"]
    F -- No --> C

A practical helper

Here’s a utility I use across projects:

const DefaultFloatTolerance = 1e-9

func FloatEquals(a, b float64) bool {
    return FloatEqualsWithTolerance(a, b, DefaultFloatTolerance)
}

func FloatEqualsWithTolerance(a, b, tolerance float64) bool {
    if math.IsNaN(a) && math.IsNaN(b) {
        return true
    }
    if math.IsInf(a, 0) && math.IsInf(b, 0) {
        return math.Signbit(a) == math.Signbit(b)
    }
    return math.Abs(a-b) <= tolerance
}

Use tolerance when your floats have been through computational journeys. Skip it for direct assignments, constants, and same-path calculations.

graph TD
    G["Grapheme Cluster\n(what users see)"]
    R1["Rune 1\n(code point)"]
    R2["Rune 2\n(combining mark)"]
    B1["Bytes\n(1-4 per rune)"]
    B2["Bytes\n(1-4 per rune)"]
    G --> R1
    G --> R2
    R1 --> B1
    R2 --> B2

1. Bytes

Go represents strings as immutable UTF-8 byte sequences.

s := "வணக்கம்"
fmt.Println(len(s)) // 21

21 bytes, not visible symbols. Every Tamil character can span 3 bytes.

2. Runes

string to []rune gives you code points.

rs := []rune(s)
fmt.Println(len(rs)) // 7

7 runes, but some Tamil graphemes (like “க்”) combine two runes: க + ்.

3. Grapheme clusters

Go’s standard library stops at runes. For visible character units, use github.com/rivo/uniseg.

for gr := uniseg.NewGraphemes(s); gr.Next(); {
    fmt.Printf("%q\n", gr.Str())
}

That outputs what a human reads: வ, ண, க், க, ம்.

graph LR
    T["வணக்கம் (Tamil)"]
    T --> |"len()"| BY["21 bytes"]
    T --> |"[]rune"| RU["7 runes"]
    T --> |"uniseg"| GR["5 graphemes"]

Quick reference

Let me say this clearly: Go is not for everything. It was never meant to be. But if you’re building cloud-native systems, if you’re working with distributed architecture, if you’re running services in production that actually matter – Go is brutal, minimal, and effective.

graph LR
    A["No generics"] -- "Go 1.18" --> B["Resolved"]
    C["No modules"] -- "Go 1.11" --> D["Resolved"]
    E["Error handling"] --> F["By Design"]
    G["Concurrency"] --> H["Same as every lang"]

Generics

Go 1.18 brought generics. Not the “look how clever I am” kind. The real-world, clean, no-BS kind. I’ve built production-grade code with generics in Go, and it’s boring in the best possible way.

Error Handling

I respect Go’s approach to error handling. It makes you look at your failure paths. There’s no magic trapdoor. You deal with errors explicitly, predictably, and with clarity. Now with errors.Is, errors.As, and errors.Join, it’s not even painful.

Go does not babysit your Concurrency

Go gives you the raw tools to build concurrent systems. It assumes the person writing the code knows what they’re doing. I respect that.

Performance

I’ve deployed Go services that boot in under 50ms and run for months without a hiccup. It doesn’t brag. It just works.

graph LR
    A["Go"] --> B["Ship fast, simple"]
    C["Java / Spring"] --> D["Medium complexity"]
    E["Rust / Haskell"] --> F["Complex, more guarantees"]

Personal take

I’ve built banking systems, transaction processors, and cloud-native APIs with Go. It’s not flashy. But Go keeps things simple and predictable, and that’s exactly what backend engineering demands.

They start with 2 KB of stack instead of 1 MB like OS threads.

They’re not wrong. But they’re not thinking deep enough.

Go’s stack model isn’t just a small preallocated buffer; it’s a live, evolving region of memory that resizes in realtime, grows when needed, and shrinks.

Go’s runtime gives each new goroutine 2 KB of stack. But Go doesn’t panic when you blow past it – it grows the stack dynamically by allocating a new region (typically doubling the size) and copying the old stack frames over.

Stack Growth Lifecycle

graph LR
    A["New Goroutine\n2 KB stack"] --> B["Function\nCall"]
    B --> C{"Stack\nCheck"}
    C -->|Enough| D["Continue\nExecution"]
    C -->|Overflow| E["Allocate\n2x Stack"]
    E --> F["Copy Old\nFrames"]
    F --> G["Update\nPointers"]
    G --> D

Each goroutine has an upper stack limit of about 1 GB. Hit it and the program panics:

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

Stack Size Progression

graph TD
    S1["2 KB\n(initial)"] --> S2["4 KB"]
    S2 --> S3["8 KB"]
    S3 --> S4["16 KB"]
    S4 --> S5["32 KB"]
    S5 --> S6["..."]
    S6 --> S7["~1 GB\n(ceiling)"]
    S7 -.->|"GC shrink\n(if idle + mostly unused)"| S5
    S5 -.->|"GC shrink"| S3

Contiguous Stack Copy

When a stack outgrows its current allocation, Go allocates a new contiguous block at double the size, copies all frames, and adjusts every internal pointer.

graph LR
    subgraph "Old Stack (4 KB)"
        O1["Frame 1"]
        O2["Frame 2"]
        O3["Pointer A\n→ Frame 1"]
    end
    subgraph "New Stack (8 KB)"
        N1["Frame 1\n(copied)"]
        N2["Frame 2\n(copied)"]
        N3["Pointer A'\n→ Frame 1\n(adjusted)"]
        N4["Free Space"]
    end
    O1 -->|copy| N1
    O2 -->|copy| N2
    O3 -->|"adjust + copy"| N3

Stack growth can trigger GC pressure even without heap allocations. A runaway stack holds pointers that get scanned by GC. This is how your 5ms p99 turns into 100ms.

There’s no tuning knob for stack size. No config. No CLI flag. The only way to manage it is through code discipline: avoid recursive goroutines unless they terminate quickly, don’t hold large structs deep in call graphs, and never assume goroutines are free.

for {
    if condition {
        break
    }
}

versus

go func() {
    for {
        // background processing
    }
}()

The runtime implications are fascinating.

The GMP Model

Go’s scheduler uses a GMP model: Goroutines (G) run on Machine threads (M) via Processors (P). Each P has a local run queue plus a global run queue.

graph TD
    subgraph "Global Run Queue"
        GQ["G5, G6, G7 ..."]
    end
    subgraph "P0 (Processor)"
        LQ0["Local Queue:\nG1, G2"]
        LQ0 --> M0["M0\n(OS Thread)"]
        M0 --> CPU0["CPU Core 0"]
    end
    subgraph "P1 (Processor)"
        LQ1["Local Queue:\nG3, G4"]
        LQ1 --> M1["M1\n(OS Thread)"]
        M1 --> CPU1["CPU Core 1"]
    end
    GQ -.->|"schedule"| LQ0
    GQ -.->|"schedule"| LQ1
    LQ0 -.->|"work steal"| LQ1

Cooperative Scheduling

sequenceDiagram
    participant S as Scheduler
    participant A as Goroutine A
    participant B as Goroutine B

    S->>A: Schedule on P0
    Note over A: Executing...
    A->>A: Channel send (yield point)
    A->>S: Yield control
    S->>B: Schedule on P0
    Note over B: Executing...
    B->>B: runtime.Gosched()
    B->>S: Yield control
    S->>A: Re-schedule on P0
    Note over A: Resumes execution

Async Preemption

Since Go 1.14, sysmon detects goroutines running longer than ~10ms and forces preemption via SIGURG.

sequenceDiagram
    participant SM as sysmon
    participant G as Goroutine (tight loop)
    participant S as Scheduler

    G->>G: Running for >10ms (no yield points)
    SM->>SM: Detects long-running G
    SM->>G: Send SIGURG
    Note over G: Signal handler fires, saves state
    G->>S: Suspended
    S->>S: Schedule next goroutine
    S->>G: Re-schedule eventually

Choosing the Right Pattern

graph LR
    A{"Need\nconcurrency?"}
    A -->|No| B["for {} loop\n(direct execution)"]
    A -->|Yes| C{"Bounded\nwork?"}
    C -->|Yes| D["Worker Pool\n(fixed goroutines)"]
    C -->|No| E{"I/O or\nCPU bound?"}
    E -->|I/O| F["Goroutine per task\n(scheduler handles blocking)"]
    E -->|CPU| G["select {} loop\n(controlled yielding)"]

For most apps, use goroutines everywhere. For the 5% of performance-critical code, choose based on your scheduler profile.

What Happens Without Self-Review

sequenceDiagram
    participant Author
    participant Reviewer
    Author->>Reviewer: Push PR for review
    Reviewer->>Author: 12 comments (typos, dead code, naming)
    Author->>Author: Fix trivial issues
    Author->>Reviewer: Push fixes
    Reviewer->>Author: 5 more comments
    Author->>Author: Fix again
    Author->>Reviewer: Push fixes
    Note over Author,Reviewer: 3+ round trips before merge

Why Self-Review Matters

a. Saves Time

Clean up obvious issues yourself so reviewers focus on architecture and design.

b. Improves Code Quality

Reading your own diff catches patterns that don’t jump out when you’re writing.

c. Builds Trust

A polished PR signals respect for your colleagues’ time.

How to Self-Review

a. View the Diff As Someone Else

Open the Files changed tab and read every line as the reviewer.

b. Check Commit Messages

Follow conventional-commit style. Each commit should represent one logical change.

c. Document Special Considerations

Add inline comments for non-obvious decisions.

d. Validate Tests

Run them locally. Check coverage for success and failure paths.

e. Check Style and Linting

Run your formatter and linter before requesting review.

What Happens With Self-Review

sequenceDiagram
    participant Author
    participant Self as Self-Review
    participant Reviewer
    Author->>Self: Read own diff as reviewer
    Self->>Author: Catch 12 trivial issues locally
    Author->>Author: Fix naming, dead code, edge cases
    Author->>Reviewer: Push clean PR
    Reviewer->>Author: 1 substantive design comment
    Author->>Author: Address feedback
    Author->>Reviewer: Push final fix
    Note over Author,Reviewer: 1 round trip to merge

Self-Review Checklist

graph TD
    Start["Open your PR diff"] --> A{"Diff readable?\nClear naming?"}
    A -->|Yes| B{"Commit messages\nclear and atomic?"}
    A -->|No| A1["Fix naming"] --> A
    B -->|Yes| C{"Tests pass?\nCoverage adequate?"}
    B -->|No| B1["Rewrite commits"] --> B
    C -->|Yes| D{"Docs updated?\nPR description clear?"}
    C -->|No| C1["Add tests"] --> C
    D -->|Yes| E{"Linting clean?"}
    D -->|No| D1["Update docs"] --> D
    E -->|Yes| F["Ready for review"]
    E -->|No| E1["Run linter"] --> E

The simplest habit that pays the biggest dividends: before clicking “Request Review”, open the Files changed tab and read every line as if a colleague wrote it.

It led me to dig deeper into the comparable constraint. With this post, I’ll walk you through what comparable is, why it’s useful, and how you can leverage it for cleaner, type-safe Go code.

Why comparable?

comparable is a constraint that ensures a type supports equality comparisons (== and !=).

In Go, only certain types are inherently comparable: primitive types like int, float64 and string, but exclude types like slices, maps, and functions.

type Array[T comparable] struct {
    data []T
}

func (a *Array[T]) Contains(value T) bool {
    for _, v := range a.data {
        if v == value {
            return true
        }
    }
    return false
}

Constraint Hierarchy

graph TD
    A["any\n(all types)"]
    B["comparable\n(supports == and !=)"]
    C["constraints.Ordered\n(supports < > <= >=)"]
    A --> B
    B --> C

any vs. interface{}

any is simply an alias for interface{}. While functionally identical, any better aligns with the intentions of generics and improves readability.

func PrintValues[T any](values []T) {
    for _, v := range values {
        fmt.Println(v)
    }
}

Real-World Scenarios

1. Deduplication with comparable

func RemoveDuplicates[T comparable](input []T) []T {
    seen := make(map[T]bool)
    result := []T{}
    for _, v := range input {
        if !seen[v] {
            seen[v] = true
            result = append(result, v)
        }
    }
    return result
}

Compile-Time vs Runtime

graph LR
    subgraph "Using any (unsafe)"
        A1["func Contains\n[T any]"] --> B1["Pass []int\nas T"]
        B1 --> C1["Runtime Panic\n== on slice"]
    end
    subgraph "Using comparable (safe)"
        A2["func Contains\n[T comparable]"] --> B2["Pass []int\nas T"]
        B2 --> C2["Compile Error\n[]int not comparable"]
    end

The real value of comparable is catching errors at compile time instead of letting them slip into production.

Program Startup Sequence

sequenceDiagram
    participant OS
    participant Runtime
    participant Packages
    participant main

    OS->>Runtime: Execute binary
    Runtime->>Runtime: Bootstrap (scheduler, GC, memory)
    Runtime->>Packages: Init packages in dependency order
    Packages->>Packages: Run init() functions
    Packages-->>Runtime: All packages initialized
    Runtime->>main: Call main()
    main->>main: Main goroutine runs
    main-->>OS: os.Exit or return

Package Dependency Ordering

Go initializes packages in dependency order, not import order. Leaf packages initialize first.

graph TD
    main["main\n(init last)"]
    A["Package A"]
    B["Package B"]
    C["Package C"]
    main --> A
    main --> B
    A --> C

Init order: C -> A -> B -> main.

Multiple init Functions

You can have multiple init functions. They run in order they appear. Go initializes packages in the order of their dependencies.

Use sync.Once when you need lazy or guarded initialization of shared resources. It’s safer than relying on init() ordering.

Exiting with os.Exit()

os.Exit() terminates the program immediately. No deferred functions run.

func main() {
    if err := doSomethingRisky(); err != nil {
        cleanup()
        os.Exit(1)
    }
}

The main Goroutine

The main function runs in a special goroutine. If main returns, the entire program exits – even if other goroutines are still working. Use sync.WaitGroup to wait for background goroutines.

Understanding Stack and Heap Memory

graph TD
    subgraph STACK["Goroutine Stack"]
        S1["Local variables"]
        S2["Function parameters"]
        S3["Return addresses"]
    end
    subgraph HEAP["Shared Heap"]
        H1["Escaped variables"]
        H2["Pointers returned\nfrom functions"]
        H3["Closure captures"]
    end
    EA{{"Escape Analysis\n(compile time)"}}
    EA -- "does not escape" --> STACK
    EA -- "escapes to heap" --> HEAP

Passing by Value: The Default Behavior

In Go, when you pass variables like integer, string, or boolean to a function, they are passed by value. A copy is made.

func increment(num int) {
    num++
}

func main() {
    n := 21
    increment(n)
    fmt.Println(n) // 21
}

Introducing Pointers

To modify the original variable inside a function, pass a pointer.

func incrementPointer(num *int) {
    (*num)++
}

func main() {
    n := 42
    incrementPointer(&n)
    fmt.Println(n) // 43
}

Escape Analysis

Escape analysis determines whether variables need to live beyond their function scope.

flowchart TD
    A["Variable declared"] --> B{"Returned as\npointer?"}
    B -- Yes --> HEAP["Allocate on Heap"]
    B -- No --> C{"Captured by\nclosure?"}
    C -- Yes --> HEAP
    C -- No --> D{"Assigned to\ninterface?"}
    D -- Yes --> HEAP
    D -- No --> E{"Too large\nfor stack?"}
    E -- Yes --> HEAP
    E -- No --> STACK["Allocate on Stack"]

Run go build -gcflags '-m' on any Go file to see escape analysis decisions.

Concurrency Issues – Data Race

func main() {
    var wg sync.WaitGroup
    counter := 0
    counterPtr := &counter
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            *counterPtr++
            wg.Done()
        }()
    }
    wg.Wait()
    fmt.Println("Counter:", *counterPtr)
}

This has a data race. Fix with a mutex:

var mu sync.Mutex
go func() {
    mu.Lock()
    *counterPtr++
    mu.Unlock()
    wg.Done()
}()

Key Takeaways

• Passing by value is simple but can be inefficient for large data structures
• Using pointers avoids copying but requires synchronization for shared access
• Escape analysis determines stack vs heap allocation
• Go prevents dangling pointers via garbage collection
• Run go test -race to detect data races

In FinTech and regulated environments, every change must be auditable and traceable. Clean Git practices are not just about developer productivity – they are a compliance requirement.

Commits

1. Write Atomic Commits

An atomic commit focuses on one thing – fixing a bug, adding a feature, or refactoring.

Good: feat: add endpoint for retrieving user account balances Bad: misc: fix bugs and add features

2. Use Descriptive Commit Messages

<type>(<scope>): <subject>
<BLANK LINE>
<body (optional)>

The Conventional Commits Specification formalizes this format. It pairs well with commitlint and enables automatic changelog generation.

graph LR
    A["feat(parser): add bitmap validation"]
    A --> B["<b>type</b><br/>feat"]
    A --> C["<b>scope</b><br/>parser"]
    A --> D["<b>description</b><br/>add bitmap validation"]

Branches

1. Follow a Consistent Naming Convention

<JIRA-ticket-ID>-<type>-<short-description>

Examples: JIRA-5678-fix-transaction-timeout, JIRA-1234-feature-add-batch-processing

2. Rebase for a Clean History

git checkout JIRA-5678-fix-transaction-timeout
git pull --rebase origin main

Rebasing rewrites commit hashes, so it should only be used on local or feature branches. The payoff is a linear history that reads like a narrative.

gitGraph
    commit id: "init"
    commit id: "v1.0"
    branch JIRA-5678-fix-timeout
    commit id: "add retry logic"
    commit id: "handle edge case"
    commit id: "add tests"
    checkout main
    commit id: "hotfix: logging"
    checkout JIRA-5678-fix-timeout
    merge main id: "rebase onto main" type: HIGHLIGHT
    checkout main
    merge JIRA-5678-fix-timeout id: "squash merge" type: HIGHLIGHT
    commit id: "v1.1"

Pull Requests

1. Use Clear PR Titles

[JIRA-ticket-ID] <Type>: <Short Description>

Examples:

• [JIRA-5678] Fix: Handle transaction timeout edge cases
• [JIRA-1234] Feature: Add bulk processing for transactions

2. Write PR Descriptions

Answer three questions: What changed? Why? Does it introduce risks?

3. Keep PRs Small

Large PRs are hard to review and prone to mistakes. A schema migration should be its own PR.

4. Self-Review First

Read your diff as if a colleague wrote it before requesting review.

graph LR
    A["Branch Created"] --> B["Commits"]
    B --> C["Self-Review"]
    C --> D["PR Opened"]
    D --> E["CI Passes"]
    E --> F["Code Review"]
    F --> G["Approved"]
    G --> H["Squash Merge"]
    H --> I["Branch Deleted"]

In highly critical FinTech systems, precision isn’t optional. Clean commits, structured branches, and clear PRs are safeguards for the stability of the systems we build.

Constants as Type-Free Values (Until They’re Used)

In Go, constants are often untyped until you actually use them. They have a default kind but can be assigned to variables of different types, as long as the value fits. This makes them adaptable in a way that’s unusual for a statically typed language.

Here’s how that looks:

const x = 10

var i int = x
var f float64 = x
var b byte = x

graph TD
    A["const x = 5\n(untyped)"] --> B["used as int"]
    A --> C["used as float64"]
    A --> D["used as byte"]
    B --> E["int"]
    C --> F["float64"]
    D --> G["byte"]

A bit analogous to Schrodinger’s paradox, x can be an int, a float64, or even a byte until you assign it. This temporary flexibility lets x work smoothly with different types in your code. No need for casting, which keeps things neat.

You can even mix constants of different types in expressions and Go will figure out the best type for the result:

const a = 1.5
const b = 2

const result = a * b // result is float64

Since a is a floating-point number, Go promotes the whole expression to float64. So you don’t have to worry about losing precision – Go handles it. But be careful: if you try to assign result to an int, you’ll get an error. Go doesn’t allow implicit conversions that might lose data.

Constants in Conditional Compilation

Go doesn’t have a preprocessor like some other languages, but you can use constants in if statements to include or exclude code at compile time.

const debug = false

func main() {
    if debug {
        fmt.Println("Debugging enabled")
    }
}

When debug is false, the compiler knows the if condition will never be true and might leave out the code inside the block. This can make your final binary smaller.

Working with Big Numbers

One powerful feature of Go’s constants is that they support very large numbers. Untyped numeric constants in Go have “infinite” precision, limited only by memory and the compiler.

const bigNum = 1e1000 // This is a valid constant

Even though bigNum is way bigger than any built-in numeric type like float64 or int, Go lets you define it as a constant. You can do calculations with these large numbers at compile time:

const (
    a = 1e20
    b = 1e30
    c = a * b // c is 1e50
)

Typed Constants with iota

If you’ve been using Go, you’ve probably seen iota for creating enumerated constants.

const (
    _ = iota
    KB = 1 << (10 * iota)
    MB
    GB
    TB
)

graph LR
    A["iota=0"] --> B["1<<0 = 1\n(Read)"]
    C["iota=1"] --> D["1<<1 = 2\n(Write)"]
    E["iota=2"] --> F["1<<2 = 4\n(Execute)"]
    B --> G["Read | Write = 3"]
    D --> G

Limitations with Constants

While Go’s constants are flexible, there are some things they can’t do.

1. Constants Cannot Be Referenced by Pointers

Constants don’t have a memory address at runtime. So you can’t take the address of a constant or use a pointer to it.

const x = 10
var p = &x // Error: cannot take the address of x

2. Function Calls in Constant Declarations

Only certain built-in functions can be used in constant expressions, like len, cap, real, imag, and complex.

const str = "hello"
const length = len(str) // This works
const pow = math.Pow(2, 3) // Error: math.Pow cannot be used in constant expressions

Go source files are UTF-8 encoded by default. You can use Unicode characters in variable names and function names. Chinese characters work fine:

package main

import "fmt"

func main() {
    消息 := "Hello, World!"
    fmt.Println(消息)
}

Attempting to Use Tamil Identifiers

I tried Tamil, my mother tongue:

package main

import "fmt"

func main() {
    எண்ணிக்கை := 42
    fmt.Println("Value:", எண்ணிக்கை)
}

But the compiler throws errors:

./prog.go:6:11: invalid character U+0BCD '்' in identifier

Why Combining Marks Fail

Tamil is an abugida. Consonant-vowel sequences are written as units with combining marks. Go’s spec allows Unicode letters in identifiers but excludes combining marks (categories Mn, Mc, Me).

graph LR
    A["Tamil syllable"] --> B["Base consonant\n(Lo: valid)"]
    A --> C["Vowel sign\n(Mc: continuation only)"]
    B --> D["Visually incomplete\nalone"]
    C --> D

Chinese vs Tamil

Chinese characters are classified under “Letter, Other” (Lo) – standalone symbols. Tamil requires combining marks, which Go’s spec explicitly excludes.

Go’s creators primarily aimed for consistent string handling through UTF-8 support. They didn’t necessarily intend for native-language coding in identifiers requiring combining marks.