Forem: Serif COLAKEL

Building a Cost-Efficient Generative UI Architecture in React Native

Serif COLAKEL — Sun, 15 Mar 2026 19:49:13 +0000

In this article, I want to share the architecture we built for Generative UI in the Fonyx mobile application. This system is designed to deliver premium native UI experiences while keeping LLM costs extremely low.

Tool Calling + Metadata-Driven Rendering

Generative UI (GenUI) is emerging as one of the most powerful patterns for AI-native applications. Instead of returning plain text responses, Large Language Models can dynamically orchestrate real UI components inside applications.

However, many early Generative UI systems face serious production challenges:

extremely high token costs
slow response times
hallucinated datasets
unpredictable UI outputs

In the Fonyx mobile application, we implemented a different architecture designed to deliver premium native UI experiences while keeping LLM costs extremely low.

The key idea behind this system is simple:

Metadata over Data

Instead of generating datasets, the model returns lightweight metadata describing what UI should render, while the client application fetches the actual data.

This dramatically improves:

performance
reliability
cost efficiency

The Core Principle: Metadata over Data

Many Generative UI systems ask the LLM to generate both:

UI structure
data payloads

Example of a common but inefficient approach:

{
  "component": "line_chart",
  "data": [
    { "date": "2024-01-01", "value": 10.21 },
    { "date": "2024-01-02", "value": 10.34 }
  ]
}

This creates two major problems.

Token Explosion

The LLM must generate large datasets as text, dramatically increasing token usage.

Higher Latency

Large responses increase generation time and Time-To-First-Token (TTFT).

The Metadata Approach

Instead, the model returns only the information needed to render the UI.

{
  "tool": "line_history_values",
  "args": {
    "fund_code": "AFT",
    "limit": 30
  }
}

The client application then performs the data request.

LLM → Select Component + Metadata
Client → Fetch Data
Client → Render Native Component

Benefits

Benefit	Result
Lower token usage	Only metadata generated
Faster responses	Minimal generation time
Higher reliability	Less hallucination risk
Native UX	Real UI components

Generative UI Architecture

This system separates AI orchestration from UI rendering.

Responsibility Split

Layer	Responsibility
LLM	Decide which component should render
Client	Fetch real data
UI	Render native interface

This prevents a common anti-pattern:

LLMs generating raw datasets.

Professional Production Architecture

Large scale Generative UI systems typically follow a three-layer architecture.

Why this architecture works

Layer	Role
LLM	decision engine
Client	orchestration
Backend	data provider

This structure keeps the system:

deterministic
scalable
cost-efficient

Tool Calling Strategy

Instead of returning free-text responses, the model uses structured tool calls.

Example tool definition:

{
  "name": "line_history_values",
  "description": "Render a fund performance chart",
  "parameters": {
    "type": "object",
    "properties": {
      "fund_code": { "type": "string" },
      "limit": { "type": "number" }
    },
    "required": ["fund_code"]
  }
}

System Prompt Strategy

A strong system prompt ensures the model only returns metadata.

Example:

You are a UI orchestration assistant.

Never generate datasets.

Only select tools and return minimal metadata.

This significantly improves tool-selection reliability.

LLM Request / Response Example

User Request

Show me the last 30 days performance of AFT fund

Request Sent to the Model

{
  "model": "stepfun/step-3.5-flash",
  "messages": [
    {
      "role": "system",
      "content": "You are a UI orchestration assistant."
    },
    {
      "role": "user",
      "content": "Show me the last 30 days performance of AFT fund"
    }
  ]
}

Model Response

{
  "tool_call": {
    "name": "line_history_values",
    "arguments": {
      "fund_code": "AFT",
      "limit": 30
    }
  }
}

Notice something important:

The LLM does not generate any dataset.

Runtime Safety with Schema Validation

LLM outputs should never be trusted blindly.

Tool arguments must be validated before rendering UI.

Example validation using Zod:

import { z } from "zod";

export const LineHistorySchema = z.object({
  fund_code: z.string().min(3).max(5).toUpperCase(),
  limit: z.number().optional().default(30),
});

Parsing tool arguments:

const parseToolArgs = (args: string) => {
  const result = LineHistorySchema.safeParse(JSON.parse(args));

  if (!result.success) {
    console.error("Invalid tool arguments");
    return null;
  }

  return result.data;
};

Validation prevents:

runtime crashes
hallucinated parameters
invalid UI props

GenUI Renderer Pattern

Tool calls map to predefined UI components.

/**
 * AI Tool isimleri ile Component eşleşmeleri için Enum tanımları.
 */
export enum GenUIComponent {
  LINE_HISTORY_VALUES = "line_history_values",
  FUND_CARD = "fund_card",
}

export type GenUIComponentProps =
  | {
      type: GenUIComponent.LINE_HISTORY_VALUES;
      props: Parameters<typeof UILineHistoryValues>[0];
    }
  | {
      type: GenUIComponent.NAV_CARD;
      props: Parameters<typeof UINavigationCard>[0];
    };

export const PickComponent = ({ type, props }: GenUIComponentProps) => {
  switch (type) {
    case GenUIComponent.LINE_HISTORY_VALUES:
      return <UILineHistoryValues {...props} />;

    case GenUIComponent.NAV_CARD:
      return <UINavigationCard {...props} />;

    default:
      return <Text>Unknown Component</Text>;
  }
};

export const UILineHistoryValues = (props: LineHistoryProps) => {
  // Client-side data fetching and rendering logic here
  // ...
  return <LineChart data={fetchedData} title={props.title} />;
};

export const UINavigationCard = (props: NavCardProps) => {
  // Client-side data fetching and rendering logic here
  // ...
  return <Card title={props.title} description={props.description} />;
};

Each component is responsible for:

Fetching its own data
Handling loading states
Rendering native UI

This keeps the AI layer extremely lightweight.

GenUI Rendering Flow

Token Cost Comparison

Traditional GenUI systems often generate large JSON datasets.

Example:

{
  "data": [
    { "date": "2024-01-01", "value": 10.23 },
    { "date": "2024-01-02", "value": 10.45 }
  ]
}

This increases token usage dramatically.

Estimated token usage

Approach	Tokens	Cost
LLM generates dataset	2000-5000	High
Metadata only	20-40	Very Low

Reducing output size from 2000 tokens to ~30 tokens can reduce cost by 100× or more.

Production GenUI Folder Structure (React Native)

A scalable project structure might look like this:

src/

  ai/
    llm/
      openrouterClient.ts

    tools/
      registry.ts
      lineHistory.tool.ts

    schemas/
      lineHistory.schema.ts

    renderer/
      PickComponent.tsx

  components/
    genui/
      UILineHistoryValues.tsx
      UINavigationCard.tsx

  services/
    apiClient.ts

  observability/
    aiTracing.ts

Key idea:

Layer	Responsibility
ai/tools	tool definitions
ai/schemas	runtime validation
ai/renderer	component picker
components/genui	native UI components
services	API communication

GenUI Caching Strategy

Caching prevents unnecessary LLM calls.

Cache Layer	Purpose
Tool decision cache	store LLM component decisions
API response cache	reuse fetched datasets
prompt cache	avoid repeated prompts

Example implementation:

const decisionCache = new Map();

export const getCachedDecision = (prompt) => {
  return decisionCache.get(prompt);
};

export const setCachedDecision = (prompt, tool) => {
  decisionCache.set(prompt, tool);
};

This reduces both latency and token cost.

AI Observability

Production AI systems must track:

token usage
latency
tool frequency
error rates

Example tracing middleware:

export const traceLLMCall = async (fn) => {
  const start = performance.now();

  const result = await fn();

  const duration = performance.now() - start;

  console.log("AI_CALL_DURATION", duration);

  return result;
};

Token tracking example:

console.log("prompt_tokens", response.usage.prompt_tokens);
console.log("completion_tokens", response.usage.completion_tokens);

Observability helps optimize both cost and performance.

Advanced Workflow Management with Effect-TS

For more complex scenarios (multi-step data fetching, retries, fallbacks), we use Effect-TS.

Effect-TS provides a powerful functional runtime for handling asynchronous workflows.

Key benefits:

Typed error handling

Dependency injection

Declarative async pipelines

Example pipeline:

import { Effect, pipe } from "effect";

const parseArgs = (args: string) =>
  Effect.try({
    try: () => LineHistorySchema.parse(JSON.parse(args)),
    catch: (e) => new Error(`Parse Error: ${e}`),
  });

const fetchData = (props: LineHistoryProps) =>
  Effect.promise(() =>
    fetch(`api/funds/${props.fund_code}/history?limit=${props.limit}`).then(
      (res) => res.json(),
    ),
  );

const renderGenUIProcess = (rawArgs: string) =>
  pipe(
    parseArgs(rawArgs),
    Effect.flatMap(fetchData),
    Effect.tap((data) => Effect.log(`Fetched ${data.length} records`)),
    Effect.catchAll((err) =>
      Effect.succeed({ error: true, message: err.message }),
    ),
  );

This ensures errors are tracked across:

parsing
data fetching
rendering

Performance Comparison

Feature	Traditional GenUI	Fonyx GenUI
Token Cost	Very High	Extremely Low
Latency	Slow	Very Fast
Data Handling	Generated by LLM	Client-side fetching
Reliability	Medium	High
UX Quality	Markdown / Text	Native UI

Future Enhancements

The architecture opens the door for more advanced AI-native UX features.

Shared Element Transitions

Smooth transitions from chat messages to full-screen visualizations.

Local LLM Fallback

Simple navigation commands handled by on-device models.

Predictive UI Prefetching

Client can preload data for likely next actions suggested by the LLM.

Why Most Generative UI Systems Fail in Production

Many Generative UI demos look impressive but fail when deployed at scale.

LLMs Used as Rendering Engines

A common mistake is asking the model to generate UI layouts.

Example:

Generate a dashboard UI for this data

This leads to:

unpredictable layouts
inconsistent UI
difficult debugging

Better pattern:

LLM decides component
Application renders UI

Models Generating Raw Datasets

Some systems ask the LLM to generate datasets.

Problems:

huge token usage
hallucinated numbers
slow responses

Instead:

LLM → metadata
Client → fetch data

Lack of Schema Validation

Without validation:

invalid props crash UI
hallucinated parameters break components

Validation is mandatory.

Prompt-Centric Architectures

Large prompts cause:

high token cost
unpredictable results
slower responses

Structured tools are more reliable.

Final Insight

Generative UI works best when the LLM acts as a decision engine, not a rendering engine.

The ideal separation is:

LLM → decision layer
Client → data layer
UI → rendering layer

This architecture allows AI-powered applications to scale to:

millions of users
deterministic UI
minimal token cost

while still delivering dynamic, intelligent user experiences.

Happy Coding! 🚀

Stop Exporting CSVs: Stream PostgreSQL to Google Sheets in Go (Production‑Ready Guide)

Serif COLAKEL — Sat, 14 Mar 2026 21:57:29 +0000

Google Sheets is often the last mile for business data.

Product managers, analysts, and operations teams love it because it's: -
collaborative - visual - familiar

But engineering teams often end up maintaining manual CSV exports or
fragile scripts to get data into Sheets.

There's a better way.

In this guide we'll build a production‑ready Google Sheets syncer in
Go that:

Streams millions of rows safely from PostgreSQL
Avoids memory explosions
Handles API quotas and retries
Writes data efficiently with chunked batch updates
Partitions datasets across sheets when they get large
Uses secure service‑account credentials

This pattern works extremely well for:

analytics exports
operational reporting
finance dashboards
product metrics
internal tooling

Let's walk through how to build it.

Why not just export CSV?

Most teams start with something like:

Run SQL query
Dump CSV
Upload to Google Sheets
Repeat via cron

This approach breaks down when:

datasets reach hundreds of thousands of rows
exports run frequently
business teams need fresh data
scripts start failing due to memory or timeouts

The better architecture:

PostgreSQL
     │
     │ stream rows
     ▼
Go Worker
     │
     │ chunk rows (2k)
     ▼
Retry + Backoff
     │
     ▼
Google Sheets API
     │
     ▼
Spreadsheet

Key idea:

Stream rows from the DB and write them in chunks to Sheets.

This avoids loading the entire dataset into memory.

Google Sheets limits you must respect

Google Sheets is not a database.

Key limits:

Limit Value

Maximum cells per spreadsheet 10,000,000
Max columns 18,278
Recommended API rate ~60 writes/min
Payload size ~10MB/request

Implications:

Write in 1k--2k row chunks
Partition large datasets across sheets
Avoid extremely wide tables

Secure credentials (never commit keys)

Use a Google Cloud service account.

Steps:

Enable Google Sheets API
Create a service account
Generate JSON key
Share spreadsheet with the service account email
Store credentials in a secret manager

Environment variables:

GOOGLE_SHEETS_CREDENTIALS_PATH=/secrets/sheets.json
GOOGLE_SHEETS_SPREADSHEET_ID=<spreadsheet-id>

Never commit keys to Git.

Project structure

A clean layout:

go-sheets-sync/
 ├─ cmd/
 │   └─ sync-job/
 │
 ├─ pkg/
 │   ├─ sheets/
 │   │   ├─ service.go
 │   │   ├─ retry.go
 │   │
 │   └─ stream/
 │       └─ streamer.go
 │
 └─ internal/
     └─ jobs/

This keeps Sheets logic reusable.

Minimal Google Sheets service

A small wrapper around the official API client.

type SheetService struct {
    srv *sheets.Service
    spreadsheetID string
}

func NewSheetService(ctx context.Context, credentialsPath, spreadsheetID string) (*SheetService, error) {
    srv, err := sheets.NewService(ctx, option.WithCredentialsFile(credentialsPath))
    if err != nil {
        return nil, fmt.Errorf("init sheets service: %w", err)
    }

    return &SheetService{
        srv: srv,
        spreadsheetID: spreadsheetID,
    }, nil
}

Batch updates are the key to performance.

func (s *SheetService) BatchUpdateValues(
    ctx context.Context,
    data map[string][][]interface{},
) error {

    var vr []*sheets.ValueRange

    for rng, vals := range data {
        vr = append(vr, &sheets.ValueRange{
            Range: rng,
            Values: vals,
        })
    }

    req := &sheets.BatchUpdateValuesRequest{
        ValueInputOption: "USER_ENTERED",
        Data: vr,
    }

    _, err := s.srv.Spreadsheets.Values.
        BatchUpdate(s.spreadsheetID, req).
        Context(ctx).
        Do()

    return err
}

One API call can write thousands of rows.

Retry with exponential backoff

Google APIs will occasionally return:

429 Too Many Requests
5xx server errors

Retries must be built in.

func withRetry(ctx context.Context, op func() error) error {

    backoff := time.Second
    maxAttempts := 6

    for attempt := 0; attempt < maxAttempts; attempt++ {

        err := op()
        if err == nil {
            return nil
        }

        if gerr, ok := err.(*googleapi.Error); ok {
            if gerr.Code != 429 && gerr.Code < 500 {
                return err
            }
        }

        jitter := time.Duration(rand.Intn(500)) * time.Millisecond

        select {
        case <-time.After(backoff + jitter):
            backoff *= 2
        case <-ctx.Done():
            return ctx.Err()
        }
    }

    return fmt.Errorf("retry attempts exhausted")
}

This makes the pipeline resilient.

Streaming rows from PostgreSQL

Never load millions of rows into memory.

Instead:

iterate DB cursor
buffer small chunks
flush to Sheets

const chunkSize = 2000

func StreamRowsToSheet(
    ctx context.Context,
    svc *SheetService,
    sheetTitle string,
    rows *sql.Rows,
) error {

    defer rows.Close()

    cols, err := rows.Columns()
    if err != nil {
        return err
    }

    batch := make([][]interface{}, 0, chunkSize)
    startRow := 2

    for rows.Next() {

        vals := make([]interface{}, len(cols))
        ptrs := make([]interface{}, len(cols))

        for i := range vals {
            ptrs[i] = &vals[i]
        }

        if err := rows.Scan(ptrs...); err != nil {
            return err
        }

        batch = append(batch, vals)

        if len(batch) >= chunkSize {

            rng := fmt.Sprintf("%s!A%d", sheetTitle, startRow)

            err := withRetry(ctx, func() error {
                return svc.BatchUpdateValues(ctx, map[string][][]interface{}{
                    rng: batch,
                })
            })

            if err != nil {
                return err
            }

            startRow += len(batch)
            batch = batch[:0]

            time.Sleep(250 * time.Millisecond)
        }
    }

    if err := rows.Err(); err != nil {
        return err
    }

    return nil
}

This pattern can stream millions of rows safely.

Partition large datasets across sheets

Remember:

1 spreadsheet = 10M cells

If you write 20 columns:

10,000,000 / 20 ≈ 500,000 rows

A safe strategy:

fund_history_1
fund_history_2
fund_history_3

Example logic:

func nextSheetIndex(rowCount int) int {
    const maxRows = 500000
    return rowCount/maxRows + 1
}

Partitioning keeps Sheets responsive.

Concurrency control

Avoid overwhelming the API.

A simple semaphore works well.

var limiter = make(chan struct{}, 3)

func limitedWrite(fn func() error) error {
    limiter <- struct{}{}
    defer func(){ <-limiter }()

    return fn()
}

Use this to cap concurrent writes.

Observability (important in production)

Add metrics like:

sheets_rows_written_total
sheets_api_requests_total
sheets_retry_total
sheets_write_latency_seconds

Also log:

batch size
retry attempts
API failures

This helps detect quota issues early.

Running the job

Example main:

func main() {

    ctx := context.Background()

    creds := os.Getenv("GOOGLE_SHEETS_CREDENTIALS_PATH")
    spreadsheetID := os.Getenv("GOOGLE_SHEETS_SPREADSHEET_ID")

    svc, err := sheets.NewSheetService(ctx, creds, spreadsheetID)
    if err != nil {
        log.Fatal(err)
    }

    job := jobs.NewSheetsUpdateJob(db)

    if err := job.Execute(ctx, svc); err != nil {
        log.Fatal(err)
    }
}

Run via:

cron
Kubernetes job
workflow scheduler

Production best practices

✔ Never commit credential JSON\
✔ Use separate spreadsheets per environment\
✔ Chunk writes (1k--2k rows)\
✔ Partition large datasets\
✔ Implement retries with backoff\
✔ Add metrics and alerts

Final thoughts

Google Sheets works best as a human‑friendly reporting surface, not
a database.

By combining:

streaming database reads
chunked API writes
exponential backoff retries
sheet partitioning
secure credential management

you can build a robust data pipeline that reliably syncs large
datasets into Google Sheets.

This approach scales surprisingly well and is used in many production
internal tools.

Happy coding 🚀

Mastering iOS Context Menus & Link Previews: React Native & Expo Router

Serif COLAKEL — Sun, 08 Mar 2026 17:44:07 +0000

When building a polished iOS application, micro-interactions matter. One of the most satisfying native interactions on iOS is the Context Menu with Link Preview—the smooth animation when you long-press a card, the background blurs, and a mini preview of the destination screen appears along with contextual actions.

Implementing this behavior in React Native has historically been complicated, relying on brittle third-party libraries or custom native modules. However, with Expo Router, this native iOS interaction can now be implemented cleanly and declaratively.

1. The Goal: A Reusable `<Preview />` Wrapper

Expo Router provides built-in components like <Link.Preview>, <Link.Menu>, and <Link.MenuAction>. However, using them directly everywhere quickly becomes repetitive—especially when dealing with dynamic or asynchronous menu items.

Instead, we created a single reusable abstraction: <Preview />. This wrapper handles:

Routing logic
Preview rendering
Async menu item resolution
Nested submenus

2. Designing Flexible Menu Types

First, we define a flexible structure for menu items to ensure type safety and support for nested submenus.

import type { LinkMenuActionProps, Href } from "expo-router";

export interface LinkMenuAction {
  title: string;
  icon?: LinkMenuActionProps["icon"];
  destructive?: boolean;
  onPress: () => void;
}

export interface LinkSubMenu {
  title: string;
  icon?: LinkMenuActionProps["icon"];
  actions: LinkMenuAction[];
}

export type LinkMenuItem = LinkMenuAction | LinkSubMenu;

3. Building the Reusable `<Preview />` Component

The core component manages the state of the menu items, allowing them to be passed as a static array or a Promise (useful for fetching data on the fly).

import { Link } from "expo-router";
import { useEffect, useState, ReactNode } from "react";

export interface WithLinkPreviewProps {
  href: Href;
  children: ReactNode;
  menuItems?: LinkMenuItem[] | Promise<LinkMenuItem[]>;
  asChild?: boolean;
}

export function Preview({ href, children, menuItems, asChild = true }: WithLinkPreviewProps) {
  const [items, setItems] = useState<LinkMenuItem[]>([]);

  useEffect(() => {
    if (!menuItems) return;

    if (menuItems instanceof Promise) {
      menuItems.then(setItems);
    } else {
      setItems(menuItems);
    }
  }, [menuItems]);

  return (
    <Link href={href} asChild={asChild}>
      <Link.Trigger>{children}</Link.Trigger>

      {items.length > 0 && (
        <Link.Menu>
          {items.map((item) => {
            if ("actions" in item) {
              return (
                <Link.Menu key={item.title} title={item.title} icon={item.icon}>
                  {item.actions.map((action) => (
                    <Link.MenuAction key={action.title} {...action} />
                  ))}
                </Link.Menu>
              );
            }
            return <Link.MenuAction key={item.title} {...item} />;
          })}
        </Link.Menu>
      )}

      <Link.Preview />
    </Link>
  );
}

4. Encapsulating Business Logic

In real applications, we wrap the <Preview /> inside domain-specific components. For example, a CalendarPreview that allows users to bookmark events directly from the list view:

export function CalendarPreview({ event, children }) {
  const { addEvent, removeEvent, mappings } = useCalendar();
  const isBookmarked = !!mappings[event.id];

  const menuItems = [{
    title: isBookmarked ? "Remove from Calendar" : "Add to Calendar",
    icon: isBookmarked ? "calendar.badge.minus" : "calendar.badge.plus",
    destructive: isBookmarked,
    onPress: () => isBookmarked ? removeEvent(event.id) : addEvent(event),
  }];

  return (
    <Preview href={`/economic-event/${event.id}`} menuItems={menuItems}>
      {children}
    </Preview>
  );
}

5. Keeping UI Components Clean

Because routing and context menu logic are fully abstracted, the main UI component remains incredibly simple and focused on layout.

const EventCard = memo(({ event }) => {
  return (
    <CalendarPreview event={event}>
      <Pressable className="rounded-xl border border-gray-200 bg-white p-4">
        <Text className="text-lg font-bold">{event.name}</Text>
        <Text className="text-sm text-gray-500">{event.time}</Text>
      </Pressable>
    </CalendarPreview>
  );
});

The Result: A Native Experience

When a user long-presses the card:

The card lifts and the background blurs.
The target screen preview appears instantly.
The Quick Actions (Add/Remove) are displayed.

Developer Takeaways

If you're building an iOS-focused React Native app, these patterns can significantly improve UX. Key lessons:

Wrap Primitives: Turn Expo Router primitives into reusable abstractions.
Decouple Logic: Keep your UI components clean by moving interaction logic to wrappers.
Native Feel: Small micro-interactions are what make a cross-platform app feel truly native.

Adding native context menus is much easier than it used to be. Once abstracted properly, you can apply this "premium" feel to any component in your app with almost zero friction.

Happy Coding 🚀!

Deterministic Testing of Concurrent Go Code

Serif COLAKEL — Sun, 15 Feb 2026 17:51:14 +0000

How to Test Goroutines Without Flaky CI Pipelines

Writing concurrent code in Go is easy.

Writing deterministic, reliable tests for concurrent code is not.

If you’ve worked on real production systems, you’ve probably seen this:

Tests pass locally.
CI fails randomly.
Increasing time.Sleep “fixes” the problem.
Flaky tests get ignored.

That’s not a tooling issue.
That’s a design issue.

In this article, we’ll go deep into:

Why time.Sleep makes your tests unreliable
How to control goroutine lifecycles properly
How to eliminate time-based nondeterminism
How to design concurrent components that are testable
Real production patterns for stable CI pipelines

This is not a beginner tutorial.
This is about writing concurrency that survives production.

1. The Root Problem: Time-Based Assumptions

Let’s start with a common anti-pattern.

func TestProcessor(t *testing.T) {
    p := NewProcessor()
    go p.Start()

    p.Enqueue(Task{ID: 42})

    time.Sleep(100 * time.Millisecond)

    if !p.HasProcessed(42) {
        t.Fatal("task not processed")
    }
}

Why is this bad?

100ms might not be enough in CI.
On a loaded machine, scheduling might delay the goroutine.
It makes your test slower than necessary.
It hides race conditions.

This test is not deterministic.
It depends on scheduler timing.

Rule #1: Tests should wait on events, not time.

2. Event-Driven Synchronization Instead of Sleep

Let’s redesign the processor to make it testable.

Step 1: Expose completion as an event

type Task struct {
    ID int
}

type Processor struct {
    tasks chan Task
    done  chan int
}

func NewProcessor() *Processor {
    return &Processor{
        tasks: make(chan Task),
        done:  make(chan int),
    }
}

func (p *Processor) Start() {
    for task := range p.tasks {
        p.process(task)
    }
}

func (p *Processor) process(task Task) {
    // real work would happen here
    p.done <- task.ID
}

func (p *Processor) Enqueue(task Task) {
    p.tasks <- task
}

Now the test becomes deterministic:

func TestProcessor(t *testing.T) {
    p := NewProcessor()
    go p.Start()

    p.Enqueue(Task{ID: 42})

    select {
    case id := <-p.done:
        if id != 42 {
            t.Fatalf("unexpected task id: %d", id)
        }
    case <-time.After(time.Second):
        t.Fatal("timeout waiting for task completion")
    }
}

Notice:

No time.Sleep
No guessing
The test reacts to an actual event

The time.After is only there to fail fast — not to “wait long enough”.

3. Goroutine Lifecycle Control (Preventing Test Leaks)

A more subtle production issue:

Your test finishes.
The goroutine keeps running.

That leads to:

Data races
Cross-test interference
Random failures
Resource leaks

Let’s fix that properly.

Structured Lifecycle Pattern

type Worker struct {
    ctx    context.Context
    cancel context.CancelFunc
    wg     sync.WaitGroup
}

Constructor:

func NewWorker(parent context.Context) *Worker {
    ctx, cancel := context.WithCancel(parent)

    return &Worker{
        ctx:    ctx,
        cancel: cancel,
    }
}

Start method:

func (w *Worker) Start() {
    w.wg.Add(1)

    go func() {
        defer w.wg.Done()

        for {
            select {
            case <-w.ctx.Done():
                return
            default:
                // simulate work loop
                time.Sleep(10 * time.Millisecond)
            }
        }
    }()
}

Stop method:

func (w *Worker) Stop() {
    w.cancel()
    w.wg.Wait()
}

Now the test:

func TestWorkerLifecycle(t *testing.T) {
    ctx := context.Background()
    w := NewWorker(ctx)

    w.Start()
    w.Stop()
}

This guarantees:

No goroutine leaks
Deterministic shutdown
Clean test isolation

In production systems, this pattern is non-negotiable.

4. Time-Dependent Logic Is a Hidden Enemy

Let’s look at a realistic example.

type RetryManager struct {
    lastAttempt time.Time
}

func (r *RetryManager) ShouldRetry() bool {
    return time.Since(r.lastAttempt) > 5*time.Second
}

How do you test this?

You can’t reliably test time-based logic using real time without sleeps.

And if you use sleeps, your test becomes:

Slow
Flaky
Environment-dependent

5. Clock Abstraction Pattern

In production systems, we abstract time.

Step 1: Define a Clock interface

type Clock interface {
    Now() time.Time
}

Step 2: Real implementation

type RealClock struct{}

func (RealClock) Now() time.Time {
    return time.Now()
}

Step 3: Fake clock for tests

type FakeClock struct {
    mu      sync.Mutex
    current time.Time
}

func NewFakeClock(start time.Time) *FakeClock {
    return &FakeClock{current: start}
}

func (f *FakeClock) Now() time.Time {
    f.mu.Lock()
    defer f.mu.Unlock()
    return f.current
}

func (f *FakeClock) Advance(d time.Duration) {
    f.mu.Lock()
    f.current = f.current.Add(d)
    f.mu.Unlock()
}

Now redesign the component:

type RetryManager struct {
    clock       Clock
    lastAttempt time.Time
}

func NewRetryManager(clock Clock) *RetryManager {
    return &RetryManager{
        clock:       clock,
        lastAttempt: clock.Now(),
    }
}

func (r *RetryManager) ShouldRetry() bool {
    return r.clock.Now().Sub(r.lastAttempt) > 5*time.Second
}

Deterministic test:

func TestRetryManager(t *testing.T) {
    fake := NewFakeClock(time.Now())
    manager := NewRetryManager(fake)

    if manager.ShouldRetry() {
        t.Fatal("should not retry yet")
    }

    fake.Advance(6 * time.Second)

    if !manager.ShouldRetry() {
        t.Fatal("should retry after time advance")
    }
}

No sleep.
No flakiness.
100% deterministic.

This pattern is extremely valuable in:

Retry systems
Circuit breakers
Rate limiters
Cache expiration logic
Background schedulers

6. Testing Concurrent State Safely

Another production pattern: shared state.

Bad example:

type Counter struct {
    value int
}

func (c *Counter) Inc() {
    c.value++
}

Concurrent test:

func TestCounter(t *testing.T) {
    c := &Counter{}
    for i := 0; i < 1000; i++ {
        go c.Inc()
    }

    time.Sleep(100 * time.Millisecond)

    if c.value != 1000 {
        t.Fatalf("expected 1000, got %d", c.value)
    }
}

This is broken in multiple ways:

Race condition
No synchronization
Sleep-based waiting

Correct implementation:

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Inc() {
    c.mu.Lock()
    c.value++
    c.mu.Unlock()
}

func (c *Counter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.value
}

Deterministic test:

func TestCounter(t *testing.T) {
    c := &Counter{}
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            c.Inc()
        }()
    }

    wg.Wait()

    if c.Value() != 1000 {
        t.Fatalf("expected 1000, got %d", c.Value())
    }
}

We wait on completion — not on time.

7. Always Run With the Race Detector

In CI:

go test -race ./...

The race detector:

Finds shared memory violations
Catches hidden concurrency bugs
Prevents production incidents

Flaky test + race warning = design issue.

Don’t ignore it.

8. Production Lessons Learned

From real systems:

Retry mechanisms caused flaky tests due to real timers.
Background workers leaked goroutines across tests.
Tests were slow because of accumulated sleeps.
CI flakiness reduced confidence in releases.

After introducing:

Event-based synchronization
Context-driven lifecycles
Clock abstraction
WaitGroup-based coordination

Results:

Flaky rate dropped to zero
Test execution time reduced significantly
Confidence in concurrent systems increased

Concurrency is not the hard part.

Testing concurrency properly is.

Final Takeaways

If your concurrent tests:

Use time.Sleep
Depend on real wall-clock time
Don’t control goroutine shutdown
Ignore race detector warnings

You’re building nondeterminism into your system.

Production-grade Go systems require:

Explicit lifecycle control
Event-driven synchronization
Time abstraction
Deterministic state verification

That’s what separates toy concurrency from production concurrency.

Go Retries: Backoff, Jitter, and Best Practices

Serif COLAKEL — Sun, 01 Feb 2026 20:13:38 +0000

In this article, we will explore how to implement production-grade retry strategies using exponential backoff, jitter, retry budgets, and circuit breakers — without leaking goroutines or memory.

Mitigating Retry Storms with Exponential Backoff, Jitter, and Retry Budgets

Modern distributed systems are built on an uncomfortable truth:
failure is not exceptional — it is normal.

Networks partition, dependencies slow down, pods restart, and databases throttle.
What separates a resilient Go service from a fragile one is not how often it fails —
but how it behaves while failing.

One of the most dangerous instincts in backend engineering is simple:

“The request failed. Let’s retry.”

Retries fix transient issues.
Retries also take down entire systems when misused.

This article dives into how retry storms emerge in Go systems, why they’re so destructive, and how to implement production-grade retry strategies using exponential backoff, jitter, retry budgets, and circuit breakers — without leaking goroutines or memory.

What a Retry Storm Actually Is

A retry storm is a positive feedback loop:

A downstream service slows down or partially fails
Clients retry failed requests
Retries increase load on the already failing service
Latency increases further
More requests fail → more retries

Eventually, the system enters a metastable failure state:
even after the original issue is fixed, traffic amplification keeps the system down.

Retry Amplification in Microservices

Consider a simple chain:

API → Order Service → Inventory Service

If both upstream services retry 3 times, a single failure at the bottom becomes:

3 × 3 = 9 requests

Now multiply that by:

thousands of goroutines
multiple replicas
auto-scaled clients

Congratulations — you just DDoS’d yourself.

The Go Anti-Pattern: Blind Retries

This pattern exists in far too many codebases:

func callRemote() error {
    for i := 0; i < 3; i++ {
        if err := doRequest(); err == nil {
            return nil
        }
    }
    return errors.New("failed after retries")
}

Why This Fails in Production

retries happen immediately
no timeout awareness
no cancellation
all clients retry at the same time

Under load, this multiplies traffic exactly when capacity is lowest.

Rule #1: Every Retry Must Be Context-Aware

A retry loop that ignores context.Context is a goroutine leak generator.

Bad

for {
    err := doRequest()
    if err == nil {
        return nil
    }
    time.Sleep(time.Second)
}

Production-Safe Pattern

func retry(ctx context.Context, attempts int, fn func() error) error {
    for i := 0; i < attempts; i++ {
        if err := fn(); err == nil {
            return nil
        }

        select {
        case <-time.After(time.Second):
        case <-ctx.Done():
            return ctx.Err()
        }
    }
    return errors.New("retry budget exhausted")
}

Now retries:

stop on request cancellation
stop on shutdown
don’t leak goroutines

Why Exponential Backoff Is Mandatory

Fixed delays don’t scale under congestion.

time.Sleep(100 * time.Millisecond) // ❌

If 10,000 clients sleep for the same duration, they wake up together.

Exponential Backoff Formula

sleep = min(cap, base × factor^attempt)

Idiomatic Go Implementation

func backoff(attempt int) time.Duration {
    base := 100 * time.Millisecond
    max := 5 * time.Second

    d := time.Duration(1<<attempt) * base
    if d > max {
        return max
    }
    return d
}

The Thundering Herd Problem (and Jitter)

Pure exponential backoff still synchronizes clients.

Add Jitter

func jitter(d time.Duration) time.Duration {
    return time.Duration(rand.Int63n(int64(d)))
}

Combined Retry Loop

func retryWithBackoff(ctx context.Context, attempts int, fn func() error) error {
    for i := 0; i < attempts; i++ {
        if err := fn(); err == nil {
            return nil
        }

        delay := jitter(backoff(i))

        select {
        case <-time.After(delay):
        case <-ctx.Done():
            return ctx.Err()
        }
    }
    return errors.New("retries exhausted")
}

This spreads retries across time instead of creating traffic spikes.

Retry Only What Is Retryable

Retries are not free — retrying the wrong errors wastes capacity.

Practical Error Classification

func isRetryable(err error, resp *http.Response) bool {
    if errors.Is(err, context.DeadlineExceeded) {
        return true
    }
    if resp == nil {
        return true // network failure
    }
    return resp.StatusCode >= 500 || resp.StatusCode == 429
}

Never retry:

validation errors
authentication failures
non-idempotent writes (unless protected)

Retry Budgets: Capping Damage

A system-wide retry budget limits retry amplification.

Rule of thumb: retries should add no more than 10% traffic

Concept

100 successful requests → earn 10 retry tokens
budget exhausted → fail fast

This ensures:

Total load ≤ 1.1 × normal traffic

Retry budgets prevent retries from becoming a denial-of-service vector.

Circuit Breakers: When to Stop Trying

Retries handle transient failure.
Circuit breakers handle systemic failure.

Proper Ordering

Retry → Circuit Breaker → Remote Call

If the breaker is open, retries must fail immediately.

State Machine

Closed: normal traffic
Open: fail fast
Half-Open: limited probe requests

Libraries like sony/gobreaker handle this efficiently and safely.

A Real Failure Story (Condensed)

During a flash sale:

Inventory service slowed down
Order service retried aggressively
traffic tripled
latency spiked from 50ms → 5s
autoscaling worsened the load
system stayed down after inventory recovered

After:

exponential backoff + jitter
retry budget (10%)
circuit breaker

Result:

traffic flattened
inventory recovered
degraded responses instead of outages

Go-Specific Pitfalls: `time.After` in Loops

Before Go 1.23, this pattern leaked timers:

select {
case <-time.After(delay):
}

In high-throughput retry loops, this caused memory pressure.

Safer Pattern

timer := time.NewTimer(delay)
defer timer.Stop()

select {
case <-timer.C:
case <-ctx.Done():
    return ctx.Err()
}

Go 1.23 improves timer GC, but explicit control is still best practice in hot paths.

Observability: Know When Retries Are Hurting You

Track:

retry count
retry delay histogram
retries / success ratio
circuit breaker state
goroutine count

A dangerous signal:

retries ≈ successful requests

That’s the edge of collapse.

Key Takeaways

Retries are load multipliers
Exponential backoff + jitter is mandatory
Context cancellation is non-negotiable
Retry budgets cap systemic damage
Circuit breakers prevent cascading failure
Unobserved retries silently kill systems

Resilience is not about retrying harder —
it’s about knowing when to stop.

Happy Coding! 🚀

Structured Concurrency in Go: Stop Letting Goroutines Escape

Serif COLAKEL — Sun, 11 Jan 2026 08:40:38 +0000

If you’ve worked with Go long enough, you’ve probably written code like this:

go doWork()

It works.
Until it doesn’t.

At some point in production, you start asking uncomfortable questions:

Why is this goroutine still running?
Who is supposed to stop this?
Why does shutdown sometimes hang?
Why do we have “random” goroutine leaks?

This isn’t a channel problem.
It’s not a mutex problem.

It’s a lifecycle problem.

What Structured Concurrency Means (Without the Buzzwords)

Structured concurrency is simple:

If you start concurrent work, you must know when and how it ends.

That’s it.

Every goroutine should have:

an owner
a clear lifetime
a cancellation signal
a place where errors go

If any of those are missing, the code might work locally — but it’s fragile in production.

The Fire-and-Forget Anti-Pattern

A very common example:

func handler(w http.ResponseWriter, r *http.Request) {
    go auditLog(r)
    processRequest(r)
}

Looks innocent.

But what happens when:

the request times out?
the client disconnects?
shutdown starts?
auditLog blocks on I/O?

You now have a goroutine:

detached from the request
uncancellable
invisible
unaccounted for

Multiply this by traffic and time.

Context Is Necessary — But Not Enough

Yes, you should pass context.Context:

go auditLog(r.Context(), r)

But context alone doesn’t:

wait for goroutines
propagate errors
coordinate siblings

You still need structure.

errgroup: Practical Structured Concurrency in Go

The most useful tool for this is:

golang.org/x/sync/errgroup

Example:

func processOrder(ctx context.Context) error {
    g, ctx := errgroup.WithContext(ctx)

    g.Go(func() error {
        return reserveInventory(ctx)
    })

    g.Go(func() error {
        return chargePayment(ctx)
    })

    g.Go(func() error {
        return notifyUser(ctx)
    })

    return g.Wait()
}

What you get:

if one fails → all are cancelled
no orphaned goroutines
clear ownership
predictable shutdown

This single pattern prevents a huge class of bugs.

Worker Pools Without Leaks

Unstructured:

for job := range jobs {
    go handle(job)
}

Structured:

g, ctx := errgroup.WithContext(ctx)

for i := 0; i < workers; i++ {
    g.Go(func() error {
        for {
            select {
            case <-ctx.Done():
                return ctx.Err()
            case job, ok := <-jobs:
                if !ok {
                    return nil
                }
                if err := handle(job); err != nil {
                    return err
                }
            }
        }
    })
}

return g.Wait()

Now:

workers stop on cancel
errors are visible
shutdown is clean

A Simple Mental Checklist

Before starting a goroutine, ask:

Who owns this goroutine?
Who cancels it?
Who waits for it?
Where does its error go?

If you can’t answer all four — it’s a bug waiting to happen.

Takeaways

Goroutines must have owners
Context enables cancellation, not structure
errgroup gives you lifecycle guarantees
Structured concurrency prevents:
- goroutine leaks
- deadlocks
- hanging shutdowns

Go doesn’t enforce this — production does.

Happy Coding! 🚀

Deadlocks in Go: The Silent Production Killer

Serif COLAKEL — Sun, 28 Dec 2025 15:22:48 +0000

“The health check is passing, CPU is idling at 2%, memory is flat… but the API is timing out.”

If you’ve managed Go services in production, you know this sinking feeling. Crashes are loud; they give you a panic log and a reboot. Deadlocks are silent. They don't trigger standard error rate alerts until the upstream clients start timing out. They are the "Ghost Ships" of concurrency bugs.

In this deep dive, we’re moving past the textbook definitions. We are going to look at how deadlocks actually manifest in real backends, how to debug a frozen process without killing it, and how to design systems that refuse to freeze.

🧠 Why the Runtime Doesn't Save You

You might know that the Go runtime has a built-in deadlock detector. You’ve seen it in main.go scripts:

fatal error: all goroutines are asleep - deadlock!

Here is the harsh reality: You will almost never see this error in a production web server.

Why? Because the deadlock detector only triggers when every single goroutine is asleep. In a real application (like a Gin or Echo server, or a Kafka consumer), there is always some goroutine running—network pollers, signal handlers, or background metric exporters.

As long as one goroutine is awake, the runtime assumes everything is fine, even if your critical business logic is stuck in a permanent mutex embrace.

🧨 Real-World Deadlock Scenarios

Let's look at how we actually break things in production.

1️⃣ The "Fintech" Lock (Mutex Ordering)

This is the classic "Transfer" problem. You need to lock two resources (User A and User B) to move funds.

type Wallet struct {
    mu      sync.Mutex
    Balance int
}

func Transfer(from, to *Wallet, amount int) {
    from.mu.Lock()
    defer from.mu.Unlock()

    // 🕒 Simulation: Network latency or context switch happens here
    time.Sleep(1 * time.Millisecond)

    to.mu.Lock()
    defer to.mu.Unlock()

    from.Balance -= amount
    to.Balance += amount
}

The Trap:
If Goroutine 1 does Transfer(A, B) and Goroutine 2 does Transfer(B, A) at the same time:

G1 holds Lock A, waits for Lock B.
G2 holds Lock B, waits for Lock A.
💀 Deadlock.

The Production Fix:
You must enforce a Deterministic Locking Order. In database terms, this is avoiding cycles. In Go, we usually sort by a unique ID (like a UUID or Database ID) before locking.

func Transfer(from, to *Wallet, amount int) {
    // Always lock the "smaller" ID first
    first, second := from, to
    if from.ID > to.ID {
        first, second = to, from
    }

    first.mu.Lock()
    defer first.mu.Unlock()

    second.mu.Lock()
    defer second.mu.Unlock()

    // logic...
}

2️⃣ The RWMutex Trap (The Recursive Read)

This one catches even senior engineers. sync.RWMutex allows multiple readers OR one writer.

The Scenario: You have a function that takes a read lock, and inside it, calls another function that also tries to take a read lock. This is fine.

The Problem: If a Writer arrives in between the two Read calls.

var mu sync.RWMutex

func ReaderA() {
    mu.RLock()
    defer mu.RUnlock()

    // Heavy work...
    ReaderB() // Calls RLock again
}

If a mu.Lock() (Write) is called while ReaderA is running but before ReaderB starts:

ReaderA holds a Read Lock.
Writer signals intent to Lock (blocks new Readers to prevent starvation).
ReaderB tries to RLock, but waits for the Writer to finish (Go implementation detail to prevent write starvation).
Writer waits for ReaderA to finish.
ReaderA is waiting for ReaderB.
💀 Deadlock.

3️⃣ The Unbuffered Channel & The Abandoned Receiver

Worker pools are great until error handling gets involved.

func processItems(items []string) {
    ch := make(chan string) // Unbuffered

    // Spawn workers
    for i := 0; i < 5; i++ {
        go func() {
            for item := range ch {
                if err := doWork(item); err != nil {
                    return // ❌ Worker exits on error!
                }
            }
        }()
    }

    // Send items
    for _, item := range items {
        ch <- item // 💀 Blocks forever if all workers exited early
    }
}

If your workers encounter errors and return (exit), there is nobody left to read from ch. The main goroutine blocks on ch <- item forever.

🔎 Detective Work: Debugging a Frozen Process

You cannot fix what you cannot see. When a pod is frozen, do not restart it immediately. You need the evidence.

1️⃣ The Full Stack Dump (pprof)

If you have net/http/pprof enabled (and you should, specifically on a private admin port), this is your smoking gun.

Don't just look at the summary. Look at the full goroutine dump with debug=2:

curl "http://localhost:6060/debug/pprof/goroutine?debug=2" > dump.txt

What to search for:

semacquire: The goroutine is waiting on a lock (Mutex or RWMutex).
chan send: Waiting to put data into a channel.
chan receive: Waiting for data that isn't coming.

If you see 5,000 goroutines all stuck on semacquire at the exact same line of code db.GetConnection(), you’ve found your bottleneck.

2️⃣ SIGQUIT (The Nuclear Option)

If you don't have pprof enabled, or the HTTP server itself is deadlocked, send a SIGQUIT to the process.

kill -QUIT <pid>

Go catches this signal and dumps the stack trace of every running goroutine to stderr (stdout in Docker logs) before exiting. It is messy, but it prints the truth.

3️⃣ `go-deadlock` (For Development)

In your staging environment, consider replacing sync.Mutex with github.com/sasha-s/go-deadlock. It is a drop-in replacement that tracks lock acquisition order. If it detects a potential deadlock or a lock held for >30 seconds, it prints a frantic stack trace. Do not use this in production (performance overhead), but it's a lifesaver in QA.

🛠 Preventing Production Freezes

We want to design systems that fail fast rather than freeze forever.

1️⃣ Context is King (The Timeout Pattern)

Never wait forever. The context package is your best defense against deadlocks.

Bad:

ch <- result // Blocks forever if receiver is gone

Good:

select {
case ch <- result:
    // Success
case <-ctx.Done():
    // Request cancelled or timed out, abandon ship
    return ctx.Err()
}

If every blocking operation (channel send/receive, DB call, HTTP request) is bound to a Context with a Timeout, deadlocks become Timeout Errors. Errors are actionable. Freezes are not.

2️⃣ Structured Concurrency (errgroup)

Stop manually managing WaitGroup counters and channels if you can avoid it. Use golang.org/x/sync/errgroup.

It handles the lifecycle for you:

It propagates Context cancellation to all workers.
If one worker returns an error, the context is cancelled, and others are notified to stop.
It waits for everyone to finish cleanly.

g, ctx := errgroup.WithContext(context.Background())

g.Go(func() error {
    return doHeavyTask(ctx)
})

// If doHeavyTask fails, ctx is cancelled immediately.
// No orphaned goroutines waiting on dead channels.
if err := g.Wait(); err != nil {
    return err
}

3️⃣ Limit Scope of Locks

Keep the critical section (the lines of code between Lock and Unlock) as small as possible.

Anti-Pattern:

mu.Lock()
defer mu.Unlock()
// ❌ Don't do I/O or network calls inside a lock!
http.Get("https://slow-api.com")
mu.State = "done"

Pattern:

resp, _ := http.Get("https://slow-api.com") // Do slow stuff outside

mu.Lock() // Lock only for the memory update
mu.State = "done"
mu.Unlock()

🔗 The Big Picture

Deadlocks are just one head of the Hydra. They are intimately connected to:

Goroutine Leaks: A deadlocked goroutine is a leaked goroutine.
Resource Exhaustion: Leaked goroutines hold stack memory (min 2KB, often more).
Graceful Shutdown: If your shutdown logic deadlocks, your deployments will hang and K8s will SIGKILL your pods, potentially corrupting data.

Understanding deadlocks forces you to think about ownership. Who owns this channel? Who owns this lock? When does this operation end?

In Go, blocking is a feature, but indefinite blocking is a bug. Always assume the other side might never answer.

Key Takeaways

Observability: Ensure pprof is accessible (securely) in production. It is the only way to debug a live deadlock.
Order Matters: Deterministic lock ordering prevents circular dependencies.
Fail Fast: Use select with time.After or ctx.Done on channels. Convert deadlocks into errors.
Avoid Recursion with Locks: Be terrified of RWMutex if you have complex call chains.

Data Races in Go: Detecting, Debugging, and Fixing Concurrency Bugs in Production

Serif COLAKEL — Sun, 21 Dec 2025 08:22:30 +0000

Concurrency is one of Go’s biggest strengths — and also one of its most subtle foot-guns.

Some of the most dangerous bugs I’ve seen in production Go systems weren’t crashes, panics, or obvious failures.
They were data races — silent, nondeterministic, and incredibly hard to reproduce.

In this article, we’ll explore:

What data races really are (beyond the textbook definition)
Why they’re dangerous in production
How to detect them with Go’s race detector
Real-world race scenarios
Production-grade patterns to eliminate them

⚠️ What Is a Data Race (In Practice)?

A data race happens when:

Two or more goroutines access the same memory location concurrently,
at least one of them writes,
and there is no synchronization.

Sounds simple — but the consequences aren’t.

Data races don’t always crash your program.
They corrupt state silently.

Why This Is Dangerous

Behavior changes between runs
Bugs appear only under load
Logs lie
Metrics look “almost correct”
Issues disappear when you add logging 😬

🧪 A Simple (but Real) Race Example

var counter int

func increment() {
    counter++
}

func main() {
    for i := 0; i < 1000; i++ {
        go increment()
    }
    time.Sleep(time.Second)
    fmt.Println(counter)
}

Expected: 1000
Reality: 🤷‍♂️ (varies every run)

🔍 Detecting Data Races with `-race`

Go ships with one of the best race detectors in the ecosystem.

Run your tests like this:

go test -race ./...

Or your app:

go run -race main.go

Example Output

WARNING: DATA RACE
Read at 0x00c0000140a8 by goroutine 6
Write at 0x00c0000140a8 by goroutine 7

This tells you:

Which variable
Which goroutines
Read vs write conflict
Exact stack traces

💡 Rule of thumb:
If you ship Go code without running -race, you’re flying blind.

🧨 Real-World Production Race Scenarios

1️⃣ Shared Struct Used by Multiple Requests

type Cache struct {
    data map[string]string
}

func (c *Cache) Get(key string) string {
    return c.data[key]
}

func (c *Cache) Set(key, value string) {
    c.data[key] = value
}

Under concurrent access → 💥 data race + map panic.

2️⃣ Metrics Counters Without Synchronization

var requests int

func handle() {
    requests++
}

This shows up a lot in:

custom metrics
logging counters
feature flags

3️⃣ Context-Aware Goroutines Writing Shared State

go func() {
    <-ctx.Done()
    status = "cancelled"
}()

If status is read elsewhere → race.

🛠 Fixing Data Races: Production Patterns

✅ Option 1: Mutex (Most Explicit)

type SafeCounter struct {
    mu sync.Mutex
    value int
}

func (c *SafeCounter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
}

✔ Clear
✔ Safe
⚠ Can hurt performance if abused

✅ Option 2: RWMutex (Read-Heavy Workloads)

type Store struct {
    mu sync.RWMutex
    data map[string]string
}

func (s *Store) Get(k string) string {
    s.mu.RLock()
    defer s.mu.RUnlock()
    return s.data[k]
}

✔ Great for caches
⚠ Still requires discipline

✅ Option 3: Atomic Operations (Small Shared State)

var counter int64

atomic.AddInt64(&counter, 1)

✔ Very fast
⚠ Limited use cases
⚠ Easy to misuse with complex logic

🧠 The Go Way: Confinement & Ownership

One of the most powerful (and underused) techniques:

Don’t share memory — share ownership.

Channel-Based Ownership Example

type Counter struct {
    inc chan struct{}
    get chan chan int
}

func NewCounter() *Counter {
    c := &Counter{
        inc: make(chan struct{}),
        get: make(chan chan int),
    }

    go func() {
        value := 0
        for {
            select {
            case <-c.inc:
                value++
            case ch := <-c.get:
                ch <- value
            }
        }
    }()
    return c
}

✔ No mutex
✔ No race
✔ Deterministic

This pattern scales beautifully in complex systems.

🧪 Race Detector in CI & Production

Best Practices

Always run -race in CI
Enable it for:
- Integration tests
- Stress tests
Run race-enabled builds in staging

⚠ Don’t use -race in production binaries
(it adds significant overhead)

🔬 Debugging Races That Don’t Reproduce

When races are hard to catch:

Increase load (stress tests)
Reduce sleeps
Use -race -count=100
Remove logging (it hides races!)
Use runtime.GOMAXPROCS

🧩 How This Connects to Previous Articles

Goroutine leaks → lifecycle ownership
Memory profiling → retention via races
Context cancellation → synchronized shutdown
Circuit breakers → safe shared state

Concurrency bugs rarely come alone.

✅ Key Takeaways

Data races are correctness bugs, not performance bugs
They are silent, nondeterministic, and dangerous
Go’s race detector is your best friend
Prefer ownership & confinement over shared memory
Make -race part of your daily workflow

Summary

In this article, we explored the ins and outs of data races in Go.
By understanding, detecting, and fixing them, you can build robust, reliable Go applications that stand strong under concurrent load.
Embrace Go’s concurrency model, and make data races a thing of the past in your codebase!

Happy coding! 🚀

My Journey to Becoming a Newly Promoted Senior Software Engineer

Serif COLAKEL — Sat, 29 Nov 2025 20:52:20 +0000

Becoming a Senior Engineer is not a title—it is a journey shaped by continuous learning, challenging projects, strong communication, and countless real-world experiences.

In this article, I want to share how I started my software career, how I progressed through different companies, and how my banking & fintech experience helped me reach the Senior level.

🧩 1. Getting Started: Building the Foundation

I started from absolute zero, spending 10–12 hours a day for nearly a year learning HTML, CSS, and JavaScript.

During this phase, I:

Learned responsive UI development
Started learning React
Attended events
Built projects such as:
- Getir Clone Web (Next.js)
- Getir Clone Mobile (React Native)
- Getir Clone API (Node.js)
- Shopify Next Payments App

These projects built my confidence and practical understanding of front-end development.

💼 2. First Job: CI/CD Fundamentals and Team Dynamics

In my first job, I worked on React-based CMS features and Next.js payment flows.
I learned:

Jenkins CI/CD
Auto-deploy pipelines
Team workflow and communication

This was my introduction to real-world engineering processes.

🚀 3. Second Company: Enterprise-Level Growth

Working as an outsourced developer for large banking projects accelerated my development significantly.

📱 BES System – React Native & React Native Web

Built cross-platform screens
Followed strict code standards (ESLint, Husky)
Learned PR/testing processes
Learned how big tech teams operate

💳 Credit Card Migration Project

Developed React Native mobile flows
Integrated banking services
Managed production incidents
Collaborated closely with testers
Improved domain knowledge

🧱 Legacy Modernization with 600+ Screens

This project was a game-changer.

I contributed to:

System analysis & architecture
Micro Frontend + Module Federation architecture
Shared UI library
Redux Toolkit Query
TailwindCSS
Storybook + Figma Design System
Dockerized environment
ESLint + Husky quality workflow
Webpack optimizations
Vendor & cross-team coordination
Production troubleshooting

This experience shaped my senior-level thinking.

🏦 4. Third Company: Full-Time Banking & Real Fintech Experience

In this role, I worked on an investment application with React Native, covering funds, equities, and FX.

Key achievements:

🧠 Code Quality & Architecture

Refactoring
Performance improvements
Modular architecture
BFF & RN Web integration (NestJS)
UI/UX improvements

📡 Real-Time FX & Stock Streaming

STOMP/WebSocket for FX
SignalR for live stock prices
Reconnection strategies
Queue management
State synchronization
Rendering optimization
Supporting other teams

📊 Monitoring & Observability

Sentry (Tracing, alerts)
Dynatrace
Dataroid
Production issue handling

👥 Scrum, Communication & Team Leadership

Acted as a Scrum Master
Held knowledge-sharing sessions
Supported testers and PO
Coordinated with vendors
Shared domain knowledge with the team

💡 Continuous Growth

Outside work:

Writing technical articles (Medium, Dev.to)
Learning Golang (concurrency + clean architecture)
Building fintech apps like funds-turkey.online
Using AI-assisted development
Studying system design and scalable architectures

⭐ What Being a Senior Means to Me

A Senior Engineer must balance:

✔ Technical expertise

✔ Communication

✔ Responsibility

✔ Continuous learning

In my view, a senior is someone who can:

Understand system architecture deeply
Solve root causes, not symptoms
Communicate clearly
Mentor others
Improve processes
Maintain product quality
Stay curious

🎉 Conclusion

I still see myself as a developer who is always learning.
Becoming a Senior is not an end—it is the beginning of a more impactful journey.

Thank you for reading. I welcome all feedback and thoughts.

Go Memory Profiling & Performance Debugging — Real-World Guide to pprof

Serif COLAKEL — Sun, 23 Nov 2025 14:30:12 +0000

Memory issues in Go aren’t always dramatic.
Sometimes they’re silent: your service boots at 200MB, runs fine, then slowly grows to 2GB+ over the day.

No panics.
No spikes in CPU.
Just… memory creep.

If you’ve ever faced this, welcome — this guide is the practical, real-world walkthrough I wish I had years ago.

In this article, we’ll explore:

how to correctly use pprof (CPU, heap, block, mutex)
how to read flamegraphs
how to diagnose true memory leaks
how to analyze production memory spikes
how concurrency patterns impact memory
real-world case studies

Let’s dive in. 🚀

🌡️ 1. pprof Basics (CPU, Memory, Block, Mutex)

Go ships with profiling tools that many languages envy. With almost no setup, you can inspect:

CPU profiling → where time is spent
Memory (heap) → what allocates / what retains
Block profiling → goroutines blocked on channels/locks
Mutex profiling → lock contention

Enabling it is simple:

import _ "net/http/pprof"

go func() {
    log.Println(http.ListenAndServe("0.0.0.0:6060", nil))
}()

Then:

curl http://localhost:6060/debug/pprof/heap > heap.out
curl http://localhost:6060/debug/pprof/profile?seconds=30 > cpu.out

Or open the UI:

go tool pprof -http=:9999 heap.out

🧠 2. alloc_space vs inuse_space (Critical!)

When reading heap profiles, you’ll see:

alloc_space

Total memory allocated over time (cumulative).
→ Great for spotting allocation-heavy functions.

inuse_space

Memory currently retained and in use.
→ This is where memory leaks appear.

Common mistake:
People confuse “allocations” with “leaks”.

A leak shows up in inuse_space, not alloc_space.

🏥 3. Case Study: “Why is my Go service using 2GB RAM?”

A very real production issue:

service normally uses ~200MB
memory grows slowly over hours
GC runs frequently
CPU normal
RAM never drops

Step 1 — Capture the heap

curl http://localhost:6060/debug/pprof/heap > heap.out

Step 2 — Inspect

go tool pprof -top heap.out

Look for:

large inuse_space
suspicious data structures
packages that shouldn’t hold memory

Step 3 — Visualize (the real magic)

go tool pprof -http=:9999 heap.out

Typical root causes:

unbounded channels
slices that grow but never shrink
caches with no eviction
goroutines stuck holding references
large buffers reused incorrectly

Every real memory issue I’ve diagnosed involved the flamegraph.

🔥 4. Reading Flamegraphs (Fast, Practical Guide)

When you open the pprof UI, the flamegraph is your best friend.

How to read it:

wide boxes = lots of memory
boxes at the bottom = root cause
bright colors = heavy allocators
tall stacks = long call chains

Look for:

a wide block at the very bottom
repeated patterns
unexpected external packages
functions returning large objects

If something looks “too wide,” it probably is.

🟢 5. Safe Production Profiling (Do’s & Don’ts)

Yes — you can run pprof in production.

✔ Safe:

heap profiles
short CPU profiles (5–15s)
mutex/block profiles
profiling internal-only endpoints

✘ Dangerous:

long CPU profiles on high-traffic systems
exposing /debug/pprof publicly
profiling during incident response without sampling

Recommended setup:

import (
    _ "net/http/pprof"
)

func init() {
    go func() {
        http.ListenAndServe("127.0.0.1:6060", nil)
    }()
}

Keep it on localhost or behind internal ingress only.

🧪 6. Production Memory Profiling Checklist

Before concluding “it’s a leak,” verify:

✔ Compare multiple heap snapshots
✔ Look at inuse_space, not alloc_space
✔ Check GC frequency (GODEBUG=gctrace=1)
✔ Capture goroutine dump (debug/pprof/goroutine)
✔ Inspect channel sizes
✔ Confirm no unbounded caches
✔ Look for large slices/maps retaining data

Memory issues rarely come from one single spot — they’re usually behavioral patterns.

⚡ 7. Memory Spikes During Traffic Surges

Traffic surges often cause:

temporary buffer spikes
batching behavior
backpressure in channels
worker pools expanding
slow consumers holding memory longer
GC pauses misaligned with load

To debug:

curl http://localhost:6060/debug/pprof/heap > spike.out
curl http://localhost:6060/debug/pprof/heap > normal.out

Then compare:

go tool pprof -diff_base normal.out spike.out

This shows what changed during the spike.

🔄 8. How Concurrency Affects Memory

Channels

Unbounded sends → memory grows.
Slow consumers → backlog accumulates.

Buffers

Large byte slices retained in memory.
Temporary buffers escaping to the heap accidentally.

sync.Pool

Useful, but not a fix-all:

no guarantee memory is freed immediately
may keep pools warm and increase RSS
bad reuse of objects → stale references

Workers

Worker pools can hide memory growth when load increases.

If concurrency increases under load → memory increases too.

🎯 Final Thoughts

Memory profiling is one of the most powerful debugging skills in Go — and one of the most underrated.

If you master:

heap profiles
flamegraphs
GC tracing
concurrency behavior

…you’ll be able to diagnose 90% of real-world performance issues in modern Go microservices.

Happy coding! 🚀

🧠 Detecting and Preventing Goroutine Leaks in Production (Leak Detection in Go)

Serif COLAKEL — Sun, 16 Nov 2025 15:30:20 +0000

Goroutines are one of Go’s biggest superpowers — lightweight, fast, and easy to spin up. But with great power comes great responsibility.
Left unchecked, goroutines can silently leak, grow in number over time, consume memory, and eventually bring down your service.

Goroutine leaks are sneaky. They often don’t break your code immediately…
but they slowly eat your system alive.

In this guide, we’ll explore:

What causes goroutine leaks
Real-world patterns that accidentally leak
How to debug them (pprof, trace, runtime APIs)
How to prevent leaks using context cancellation and proper channel patterns
Production-ready best practices

Let’s dive in. 🚀

❗ What Is a Goroutine Leak?

A goroutine leak happens when a goroutine never exits, usually because it is:

blocked on a channel
waiting on a select case that never fires
stuck on I/O
waiting for a context that is never cancelled
part of a consumer/producer pipeline with no exit condition

Over time, the number of goroutines grows:

fmt.Println(runtime.NumGoroutine())

If this spikes over hours/days, you probably have a leak.

🐛 A Classic Example of a Goroutine Leak

Here’s a typical bug many developers run into:

func worker(jobs <-chan int) {
    for {
        job := <-jobs
        fmt.Println("processing", job)
    }
}

func main() {
    jobs := make(chan int)

    go worker(jobs)

    // Never sends jobs
    time.Sleep(5 * time.Second)
}

What happens?

worker() blocks forever on <-jobs
No jobs ever arrive
The goroutine never exits
Boom — leak

Now imagine this in a loop spawning workers every request.
That’s how production incidents happen.

⚠️ Real-World Leak Scenario: Cancelling Requests Without Cancelling Goroutines

This is one of the top 3 causes of leaks in production.

func fetch(ctx context.Context) error {
    ch := make(chan string)

    go func() {
        time.Sleep(5 * time.Second)
        ch <- "done"
    }()

    select {
    case <-ctx.Done():
        return ctx.Err()
    case v := <-ch:
        fmt.Println("response:", v)
        return nil
    }
}

Problem:
If the context is cancelled, the goroutine is not stopped.
It keeps sleeping, then tries to send into ch where nobody is listening → goroutine leak.

🧯 Fixing the Leak with Cancellation Propagation

Use context to tell goroutines when to stop:

go func() {
    defer close(ch)

    select {
    case <-time.After(5 * time.Second):
        ch <- "done"
    case <-ctx.Done():
        return
    }
}()

Now the goroutine exits gracefully when the context is cancelled.

🕳️ Hidden Leak: Unbounded Goroutine Spawning

Sneaky production issue:

http.HandleFunc("/search", func(w http.ResponseWriter, r *http.Request) {
    go expensiveOperation()
})

Under load:
100 req/sec → 100 goroutines/sec → 6,000 goroutines/min → goodbye memory.

Fix: use a worker pool (bounded concurrency).

🧵 Leaks in Channels and Pipelines

Pipeline pattern gone wrong:

func generator() <-chan int {
    ch := make(chan int)

    go func() {
        for i := 0; i < 10; i++ {
            ch <- i
        }
    }()

    return ch
}

Problem: channel never closes → consumer blocks forever.

Fix:

go func() {
    defer close(ch)
    for i := 0; i < 10; i++ {
        ch <- i
    }
}()

🔎 How to Detect Goroutine Leaks in Production

1. `runtime.NumGoroutine()`

Track this metric in Prometheus:

go_goroutines

If it constantly grows → 🔥 leak.

2. pprof (Goroutine Profiles)

Enable pprof:

import _ "net/http/pprof"

go http.ListenAndServe(":6060", nil)

Then inspect goroutines:

go tool pprof http://localhost:6060/debug/pprof/goroutine

Look for:

goroutines stuck on <-chan
“waiting for lock”
“sleeping”
same stack repeated thousands of times

3. `go trace`

Trace gives a timeline of goroutine lifecycle:

go test -trace trace.out
go tool trace trace.out

You'll see goroutines that:

never complete
block on channels
block on network I/O

4. Heap Growth

Leaked goroutines capture memory:

closure variables
buffers
context
network state

If heap grows in parallel with goroutines → confirmed leak.

🛠 Best Practices to Prevent Goroutine Leaks

1. Always use context with goroutines

go func(ctx context.Context) {
    select {
    case <-ctx.Done():
        return
    case v := <-ch:
        _ = v
    }
}(ctx)

2. Close channels when done

Producer closes, not consumer:

close(results)

3. Avoid unbounded goroutine creation

Use worker pools:

sem := make(chan struct{}, 10) // max 10 concurrent tasks

sem <- struct{}{}
go func() {
    defer func() { <-sem }()
    doWork()
}()

4. Use `select` with defaults to avoid deadlocks

select {
case jobs <- job:
default:
    log.Println("job queue full")
}

5. Timeouts for every external call

Never trust remote systems:

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

6. Monitor goroutine count aggressively

Set alerts:

if go_goroutines > 2000 (and keeps increasing)
    alert: "Possible goroutine leak"

📌 Checklist: Before shipping Go code to production

✅ Do all goroutines have a way to exit?
✅ Are contexts cancelled?
✅ Are channels closed when done?
✅ Is concurrency bounded?
✅ Are there blocking operations inside goroutines?
✅ Do we monitor goroutine count?

🎯 Final Thoughts

Goroutine leaks are one of the most common hidden problems in Go microservices — especially under real production load.

By understanding how leaks happen and using proper patterns (context cancellation, closing channels, bounded concurrency), you can:

prevent memory bloat
avoid production outages
keep your services reliable and fast
confidently observe and debug concurrency issues

Happy debugging & happy coding! 🔥🐹

🧠 Circuit Breaker Patterns in Go Microservices

Serif COLAKEL — Sun, 09 Nov 2025 14:53:08 +0000

In this article, we’ll explore the Circuit Breaker pattern — a crucial design pattern for building resilient microservices in Go.

Building Self-Healing and Fault-Tolerant Systems

When designing distributed systems, it’s not a question of if something will fail — it’s when.
Even the most stable services can occasionally hang, slow down, or fail under high load.

In production systems, retries and backoff strategies help, but sometimes they’re not enough.
That’s where Circuit Breaker patterns come in — providing a way to gracefully degrade your system instead of letting failures cascade.

💡 What Is a Circuit Breaker?

A Circuit Breaker acts like an electrical switch.
When a downstream service starts failing too often, the breaker “opens” — stopping further requests and giving the failing system time to recover.

It prevents resource exhaustion, retry storms, and latency chain reactions across your microservices.

Circuit Breaker States:

Closed → Everything works fine. Requests flow normally.
Open → Too many failures occurred. Stop requests immediately.
Half-Open → Test a few requests to check if recovery happened.

⚙️ Example: Implementing a Simple Circuit Breaker in Go

Let’s simulate a production scenario: a Go service calling a flaky downstream API.

package main

import (
    "errors"
    "fmt"
    "sync"
    "time"
)

type CircuitBreaker struct {
    failureCount     int
    lastFailureTime  time.Time
    state            string // "closed", "open", "half-open"
    mu               sync.Mutex
    threshold        int
    resetTimeout     time.Duration
}

func NewCircuitBreaker(threshold int, resetTimeout time.Duration) *CircuitBreaker {
    return &CircuitBreaker{
        threshold:    threshold,
        resetTimeout: resetTimeout,
        state:        "closed",
    }
}

func (cb *CircuitBreaker) Call(fn func() error) error {
    cb.mu.Lock()
    defer cb.mu.Unlock()

    switch cb.state {
    case "open":
        if time.Since(cb.lastFailureTime) > cb.resetTimeout {
            cb.state = "half-open"
        } else {
            return errors.New("circuit breaker: open (request blocked)")
        }
    }

    err := fn()
    if err != nil {
        cb.failureCount++
        cb.lastFailureTime = time.Now()
        if cb.failureCount >= cb.threshold {
            cb.state = "open"
            fmt.Println("⚠️ Circuit breaker opened!")
        }
        return err
    }

    // success
    cb.failureCount = 0
    if cb.state == "half-open" {
        cb.state = "closed"
        fmt.Println("✅ Circuit breaker closed (service recovered)")
    }
    return nil
}

Usage Example

func flakyService() error {
    if time.Now().UnixNano()%2 == 0 {
        return errors.New("temporary network error")
    }
    return nil
}

func main() {
    cb := NewCircuitBreaker(3, 5*time.Second)

    for i := 0; i < 10; i++ {
        err := cb.Call(flakyService)
        if err != nil {
            fmt.Println("Request failed:", err)
        } else {
            fmt.Println("Request succeeded!")
        }
        time.Sleep(500 * time.Millisecond)
    }
}

🧩 Output (simplified):

Request succeeded!
Request failed: temporary network error
Request failed: temporary network error
⚠️ Circuit breaker opened!
Request failed: circuit breaker: open (request blocked)
✅ Circuit breaker closed (service recovered)

🔁 Integration with Retry and Backoff

Circuit breakers shine when combined with retry and backoff patterns (as covered in your previous article).

Example: you can wrap the breaker call with a retry function.

func resilientCall(cb *CircuitBreaker, fn func() error) error {
    for i := 0; i < 3; i++ {
        err := cb.Call(fn)
        if err == nil {
            return nil
        }
        time.Sleep(time.Duration(i+1) * 200 * time.Millisecond)
    }
    return errors.New("all retries failed")
}

This gives you layered resilience:

Retry with exponential backoff for transient errors
Circuit breaker for systemic failures

🧩 Production-Ready Alternatives

You don’t always need to reinvent the wheel.
Some great open-source implementations exist for Go:

sony/gobreaker – production-proven, simple API
afex/hystrix-go – Netflix-style circuit breaker
go-resilience – includes retry, timeout, and breaker

Example using sony/gobreaker:

import "github.com/sony/gobreaker"

var cb *gobreaker.CircuitBreaker

func init() {
    st := gobreaker.Settings{
        Name:        "HTTPClient",
        MaxRequests: 5,
        Interval:    0,
        Timeout:     10 * time.Second,
        ReadyToTrip: func(counts gobreaker.Counts) bool {
            return counts.ConsecutiveFailures > 3
        },
    }
    cb = gobreaker.NewCircuitBreaker(st)
}

🔍 Observability and Metrics

To make circuit breakers production-grade, track:

Success/failure rates
Open/close transitions
Latency during half-open state
Log structured events for monitoring

Integration with Prometheus, Grafana, or OpenTelemetry gives you full visibility.

💬 Key Takeaways

✅ Circuit breakers protect your systems from cascading failures.
✅ Combine them with retry, backoff, and rate limiting for full resilience.
✅ Use context cancellation to cleanly handle timeout or shutdown scenarios.
✅ Always monitor breaker state transitions in production.

Happy Coding! 🚀

Forem: Serif COLAKEL

Building a Cost-Efficient Generative UI Architecture in React Native

Tool Calling + Metadata-Driven Rendering

The Core Principle: Metadata over Data

Token Explosion

Higher Latency

The Metadata Approach

Benefits

Generative UI Architecture

Responsibility Split

Professional Production Architecture

Why this architecture works

Tool Calling Strategy

System Prompt Strategy

LLM Request / Response Example

User Request

Request Sent to the Model

Model Response

Runtime Safety with Schema Validation

GenUI Renderer Pattern

GenUI Rendering Flow

Token Cost Comparison

Estimated token usage

Production GenUI Folder Structure (React Native)

GenUI Caching Strategy

AI Observability

Advanced Workflow Management with Effect-TS

Performance Comparison

Future Enhancements

Why Most Generative UI Systems Fail in Production

LLMs Used as Rendering Engines

Models Generating Raw Datasets

Lack of Schema Validation

Prompt-Centric Architectures

Final Insight

Stop Exporting CSVs: Stream PostgreSQL to Google Sheets in Go (Production‑Ready Guide)

Why not just export CSV?

Google Sheets limits you must respect

Secure credentials (never commit keys)

Project structure

Minimal Google Sheets service

Retry with exponential backoff

Streaming rows from PostgreSQL

Partition large datasets across sheets

Concurrency control

Observability (important in production)

Running the job

Production best practices

Final thoughts

Mastering iOS Context Menus & Link Previews: React Native & Expo Router

1. The Goal: A Reusable <Preview /> Wrapper

2. Designing Flexible Menu Types

3. Building the Reusable <Preview /> Component

4. Encapsulating Business Logic

5. Keeping UI Components Clean

The Result: A Native Experience

Developer Takeaways

Deterministic Testing of Concurrent Go Code

How to Test Goroutines Without Flaky CI Pipelines

1. The Root Problem: Time-Based Assumptions

2. Event-Driven Synchronization Instead of Sleep

Step 1: Expose completion as an event

3. Goroutine Lifecycle Control (Preventing Test Leaks)

Structured Lifecycle Pattern

4. Time-Dependent Logic Is a Hidden Enemy

5. Clock Abstraction Pattern

Step 1: Define a Clock interface

Step 2: Real implementation

Step 3: Fake clock for tests

6. Testing Concurrent State Safely

7. Always Run With the Race Detector

8. Production Lessons Learned

Final Takeaways

Go Retries: Backoff, Jitter, and Best Practices

Mitigating Retry Storms with Exponential Backoff, Jitter, and Retry Budgets

What a Retry Storm Actually Is

Retry Amplification in Microservices

The Go Anti-Pattern: Blind Retries

Why This Fails in Production

Rule #1: Every Retry Must Be Context-Aware

1. The Goal: A Reusable `<Preview />` Wrapper

3. Building the Reusable `<Preview />` Component

Go-Specific Pitfalls: `time.After` in Loops

3️⃣ `go-deadlock` (For Development)

🔍 Detecting Data Races with `-race`