Forem: Fazal Mansuri

⚠️ Race Conditions in APIs - The Bug You Can’t See

Fazal Mansuri — Sat, 18 Apr 2026 09:02:13 +0000

There's a category of bugs that don't show up in tests. They don't throw errors. They don't crash your server. They just silently corrupt your data at the exact moment two users do the same thing at the same time.

That's a race condition.

And if you've ever seen a user's account balance go wrong, a product's stock count go negative, or a post get double-liked - you've seen one in production.

Let's break down exactly what's happening and how to fix it.

What Is a Race Condition?

A race condition happens when two concurrent operations read shared data, make a decision based on it, and write back — and neither knows the other exists.

The classic example:

Thread A reads stock = 10
Thread B reads stock = 10
Thread A writes stock = 9  (decremented by 1)
Thread B writes stock = 9  (also decremented from 10 — wrong!)

Two orders placed. One decrement applied. You just oversold your inventory.

The reason this is invisible: each individual operation is correct. Thread A did nothing wrong. Thread B did nothing wrong. The bug lives in the gap between the read and the write.

A Real Scenario: The Inventory API

Say you have an endpoint that handles a purchase:

// ❌ NOT safe under concurrent load
func purchaseItem(ctx context.Context, itemID string) error {
    var stock int
    err := db.QueryRow("SELECT stock FROM items WHERE id = $1", itemID).Scan(&stock)
    if err != nil {
        return err
    }

    if stock <= 0 {
        return errors.New("out of stock")
    }

    _, err = db.Exec("UPDATE items SET stock = $1 WHERE id = $2", stock-1, itemID)
    return err
}

This looks fine. In a single-user world, it is fine. But under load — say, a flash sale with 500 concurrent requests — the gap between SELECT and UPDATE is enough for dozens of threads to read the same stock value and all decrement from it simultaneously.

Result: Negative stock. Oversold orders. Angry customers.

Three Ways to Fix It

Fix 1 — Atomic SQL Update (the simplest approach)

The fastest fix is to eliminate the read-then-write pattern entirely and let the database handle the decrement atomically:

// ✅ Safe — single atomic statement
result, err := db.Exec(`
    UPDATE items
    SET stock = stock - 1
    WHERE id = $1 AND stock > 0
`, itemID)

rowsAffected, _ := result.RowsAffected()
if rowsAffected == 0 {
    return errors.New("out of stock or already taken")
}

No read. No gap. The database engine serializes this at the row level. This works well for simple decrements and is the right default when you don't need the old value.

Fix 2 — Pessimistic Locking (SELECT FOR UPDATE)

When you genuinely need to read the value before deciding what to write — for example, checking business rules before an update — use SELECT FOR UPDATE to hold a row lock:

// ✅ Safe — row is locked until transaction commits
tx, _ := db.BeginTx(ctx, nil)
// error handling omitted for brevity
defer tx.Rollback()

var stock int
err := tx.QueryRow(`
    SELECT stock FROM items WHERE id = $1 FOR UPDATE
`, itemID).Scan(&stock)

if stock <= 0 {
    return errors.New("out of stock")
}

tx.Exec("UPDATE items SET stock = $1 WHERE id = $2", stock-1, itemID)
tx.Commit()

FOR UPDATE tells the database: lock this row. Any other transaction that tries to read it with FOR UPDATE will block until this one commits or rolls back. Completely safe — but it creates a queue, so it can become a bottleneck under heavy concurrent traffic.

Fix 3 — Optimistic Locking with CAS (Compare-And-Swap)

Optimistic locking says: don't block anyone. Just verify before writing that the world still looks the way you expected when you read it.

You add a version column to the row, then make your update conditional:

// ✅ Safe — version mismatch causes retry, not corruption
type Item struct {
    ID      string
    Stock   int
    Version int
}

func purchaseWithCAS(ctx context.Context, itemID string) error {
    const maxRetries = 3

    for attempt := 0; attempt < maxRetries; attempt++ {
        var item Item
        db.QueryRow("SELECT id, stock, version FROM items WHERE id = $1", itemID).
            Scan(&item.ID, &item.Stock, &item.Version)

        if item.Stock <= 0 {
            return errors.New("out of stock")
        }

        result, _ := db.Exec(`
            UPDATE items
            SET stock = $1, version = $2
            WHERE id = $3 AND version = $4
        `, item.Stock-1, item.Version+1, item.ID, item.Version)

        rows, _ := result.RowsAffected()
        if rows == 1 {
            return nil // success
        }
        // version mismatch — someone else wrote first, retry
    }
    return errors.New("too many concurrent modifications, try again")
}

If two threads both read version=5, only the first one that writes version=6 wins. The second sees rowsAffected=0 and retries with a fresh read. No locks held, no blocking — just retry on conflict.

When to Use Which Fix

Scenario	Best approach
Simple increment/decrement	Atomic SQL (`UPDATE ... SET x = x - 1`)
Complex business logic before write	Pessimistic locking (`SELECT FOR UPDATE`)
High-read, low-conflict workloads	Optimistic locking (CAS + version)
Distributed systems / no shared DB	Distributed locks (Redis `SET NX`, etc.)

The Distributed Case: Redis to the Rescue

When your API runs across multiple servers and the database lock isn't enough (or too slow), you need a distributed lock. Redis handles this elegantly:

// ✅ Distributed lock using Redis SET NX (set if not exists)
func acquireLock(ctx context.Context, rdb *redis.Client, key string, ttl time.Duration) (bool, error) {
    ok, err := rdb.SetNX(ctx, "lock:"+key, "1", ttl).Result()
    return ok, err
}

func releaseLock(ctx context.Context, rdb *redis.Client, key string) {
    rdb.Del(ctx, "lock:"+key)
}

func purchaseWithRedisLock(ctx context.Context, rdb *redis.Client, db *sql.DB, itemID string) error {
    acquired, err := acquireLock(ctx, rdb, itemID, 5*time.Second)
    if err != nil || !acquired {
        return errors.New("could not acquire lock, try again")
    }
    defer releaseLock(ctx, rdb, itemID)

    // safe to read and write now — only one server can be here at a time
    return purchaseItem(ctx, db, itemID)
}

The SET NX command is atomic in Redis — only one caller gets true. All others get false and back off. The TTL ensures the lock is released even if your server crashes mid-operation.

⚠️ One important caveat: SET NX alone isn't enough for production. Use Redlock (Redis's official distributed locking algorithm) when you need strong guarantees — especially if you have multiple Redis nodes.

Summary: The Mental Model

Race conditions happen in the gap between read and write. The longer that gap, the higher the chance of corruption. Your goal is to shrink or eliminate that gap:

Atomic operations collapse the gap to zero.
Pessimistic locks block others from entering the gap.
Optimistic locks let everyone in but detect and reject stale writes.

There's no universally best answer. Pick the approach that matches your read/write ratio, your tolerance for blocking, and whether your system is distributed.

Key Takeaways

A race condition is not a bug in any single thread — it's a bug in timing between threads.
Any "read, decide, write" pattern is vulnerable unless protected.
The simplest fix is often a single atomic SQL statement — reach for it first.
SELECT FOR UPDATE is your safety net when you need business logic between the read and write.
Optimistic locking with a version column is ideal for high-concurrency, low-conflict scenarios.
In distributed systems, move to Redis-based locking.

Have you been bitten by a race condition in production? How did you track it down? Drop a comment - these bugs have some of the best war stories.

🚀 Feature Flags - The Secret Behind Safe Deployments

Fazal Mansuri — Sun, 15 Mar 2026 07:49:04 +0000

Shipping software used to be risky.

A new deployment could introduce bugs, break critical workflows or affect thousands (or millions) of users instantly.

For many teams, releasing software meant:

Deploying late at night 🌙
Monitoring dashboards anxiously 📊
Hoping nothing breaks 🤞

Modern engineering teams solved this problem using Feature Flags.

Feature flags allow developers to release code without immediately exposing new features to users.

Instead of deploying and hoping everything works, teams can control feature visibility dynamically.

🧠 What Are Feature Flags?

A Feature Flag (also called a Feature Toggle) is a mechanism that enables or disables functionality in an application without deploying new code.

In simple terms:

if feature_flag_enabled:
    show_new_feature()
else:
    use_old_behavior()

The application contains both code paths, but the feature flag decides which one runs.

This allows developers to separate deployment from release.

Key idea:

Deployment → Shipping code to production
Release → Making the feature available to users

Feature flags allow these two processes to happen independently.

🎯 Why Feature Flags Matter

Feature flags dramatically reduce the risk of releasing software.

Without Feature Flags

Deploy → Feature immediately live

If something breaks, the only option is rollback.

With Feature Flags

Deploy → Feature disabled → Enable gradually

If something goes wrong, simply turn the feature off.

No redeployment required.

Benefits of Feature Flags

Feature flags enable:

✅ Safer releases
✅ Gradual rollouts
✅ Instant rollback
✅ Production testing
✅ Controlled experiments

🛒 Real-World Example

Imagine launching a new checkout system for an e-commerce platform.

Without Feature Flags

Deploy new checkout → All users see it

If checkout fails → Revenue stops immediately 💥

With Feature Flags

Deploy new checkout → Feature disabled
Enable for 5% users
Monitor metrics
Gradually increase rollout

If problems appear, the feature can be disabled instantly.

🧩 Types of Feature Flags

Not all feature flags are used for the same purpose.

Understanding their types helps design systems properly.

1️⃣ Release Flags

Used to gradually release new features.

Example:

new_checkout_enabled

Purpose:

Control feature rollout
Reduce release risk

Release flags are usually temporary and removed once the feature is stable.

2️⃣ Experiment Flags (A/B Testing)

Used for product experiments.

Example:

checkout_variant_A
checkout_variant_B

Users may see different versions of a feature.

Metrics measured include:

📈 Conversion rate
📊 Engagement
🔁 Retention

3️⃣ Operational Flags

Used to control system behavior during incidents.

Example:

disable_recommendation_engine

If a system starts failing, the feature can be disabled instantly.

Operational flags are useful during production outages.

4️⃣ Permission Flags

Used to control access based on user roles.

Example:

admin_dashboard_enabled

Only certain users or roles see the feature.

This is commonly used for:

internal tools
beta programs
admin dashboards

⚙️ Feature Flags vs Configuration Flags

These concepts are often confused.

Feature Flags

Used to control product functionality.

Characteristics:

Temporary
Used for rollouts
Tied to releases

Example:

enable_new_upload_ui = true

Configuration Flags

Used to control system configuration.

Characteristics:

Usually permanent
Not tied to releases

Example:

max_upload_size = 20MB

Understanding this difference prevents misuse of feature flags.

🧪 Simple Implementation Example (Go)

Here is a simple feature flag example in Go:

type FeatureFlags struct {
    NewCheckout bool
}

func Checkout(flags FeatureFlags) {
    if flags.NewCheckout {
        newCheckoutFlow()
    } else {
        oldCheckoutFlow()
    }
}

Feature flag values may come from:

configuration files
environment variables
databases
remote config services

🌐 Remote Feature Flag Systems

In production, feature flags are often managed remotely.

Popular platforms include:

LaunchDarkly
Split
Flagsmith

These systems allow teams to:

toggle features instantly ⚡
target specific users 🎯
monitor rollout metrics 📊

No redeployment required.

📈 Gradual Rollouts

One of the most powerful capabilities of feature flags is progressive rollout.

Example rollout strategy:

1% users → monitor
10% users → monitor
50% users → monitor
100% users → full release

This dramatically reduces release risk.

Problems can be detected before the feature reaches everyone.

🎯 Targeted Rollouts

Feature flags can also target specific user segments.

Examples:

internal employees
beta testers
specific countries
premium users

Example logic:

if user.country == "US":
    enable_feature()

This enables testing directly in production environments.

🐤 Canary Releases

Feature flags are commonly used with canary releases.

A canary release exposes a feature to a small subset of users first.

This helps detect:

performance issues
unexpected errors
unusual user behavior

before rolling it out globally.

🌑 Dark Launching

Another advanced technique is Dark Launching.

The feature is deployed but hidden from users.

The system still runs the feature in the background to test performance.

Example:

recommendation_engine_running = true
recommendation_visible = false

This helps test infrastructure safely before exposing the feature.

⚠️ The Hidden Problem: Feature Flag Debt

Feature flags are powerful, but they introduce a new problem:

Feature Flag Debt

Over time, many flags remain in the codebase long after the feature is released.

Example:

if old_feature_flag:

But the feature is already permanent.

This leads to:

messy code
confusion
technical debt

Flags should be removed once they are no longer needed.

🚨 Common Mistakes With Feature Flags

Many teams misuse feature flags.

Here are common pitfalls.

1️⃣ Flag Explosion

Too many flags make systems difficult to understand.

Every flag increases system complexity.

2️⃣ Flags in Performance-Critical Paths

Checking flags in very hot paths may affect performance.

Flag evaluation should be fast and lightweight.

3️⃣ Long-Lived Release Flags

Release flags should be temporary.

Once rollout finishes, remove them.

4️⃣ Mixing Flags With Business Logic

Feature flags should control behavior, not implement complex logic.

Avoid deeply nested conditions like:

if flagA and not flagB and flagC

✅ Best Practices

Successful teams follow several important practices.

1️⃣ Treat Flags as Temporary

Every release flag should have an expiration plan.

2️⃣ Track Flag Ownership

Each flag should have an owner responsible for cleanup.

3️⃣ Monitor Feature Rollouts

Always observe metrics when enabling a feature.

Examples:

error rate
latency
user behavior

4️⃣ Use Clear Naming

Bad naming:

flag123

Better naming:

checkout_v2_release

Clear names improve maintainability.

5️⃣ Remove Flags After Release

Cleaning up unused flags keeps the codebase healthy.

⚡ Feature Flags Enable Modern DevOps

Feature flags are a key component of modern engineering practices.

They enable:

🚀 Continuous deployment
🧪 Safe experimentation
🔄 Instant rollbacks
🎯 Controlled feature releases

Instead of fearing deployments, teams can release features with confidence.

🏁 Final Thoughts

Feature flags fundamentally change how software is delivered.

They transform deployments from risky events into controlled experiments.

But like any powerful tool, they must be used carefully.

Without discipline, feature flags can create complexity and technical debt.

When implemented correctly, they become one of the most powerful tools in a developer’s toolbox.

Idempotency in APIs - Why Your Retry Logic Can Break Everything (And How to Fix It)

Fazal Mansuri — Sun, 22 Feb 2026 11:22:55 +0000

Modern applications rely heavily on APIs. But networks are unreliable - requests fail, time out, or get retried.

Now imagine this scenario:

User clicks “Pay Now”
Request sent to server
Payment processed successfully
But response is lost due to network issue
Client retries the request

💥 Payment gets processed again. User is charged twice.

This is one of the most dangerous and common problems in distributed systems.

The solution? Idempotency.

What is Idempotency?

An operation is idempotent if performing it multiple times produces the same result as performing it once.

In simple terms:

Same request → same effect → no duplicate side effects

Example:

Create Order (without idempotency):
Request sent twice → 2 orders created ❌

Create Order (with idempotency):
Request sent twice → only 1 order created ✅

Idempotency ensures system correctness even when retries happen.

Why Do Retries Happen?

Retries are extremely common due to:

Network timeouts
Server crashes
Client retries
Load balancers retrying requests
Mobile networks instability
API gateway retries
Reverse proxy retries

Retries are normal. Duplicate side effects are not.

Which HTTP Methods Are Idempotent?

According to HTTP specification:

Method	Idempotent	Explanation
GET	✅ Yes	Fetch data
PUT	✅ Yes	Replace resource
DELETE	✅ Yes	Delete resource
POST	❌ No	Create resource
PATCH	❌ No	Partial update

POST is NOT idempotent by default.

Example:

POST /orders

Calling twice → creates 2 orders.

This must be handled explicitly.

Real-World Example: Payment API Problem

Client sends:

POST /payments
{
  "user_id": "123",
  "amount": 100
}

If client retries due to timeout:

POST /payments

Without idempotency → duplicate payment ❌

With idempotency → single payment ✅

Solution: Idempotency Key

Client sends a unique key with request:

POST /payments
Idempotency-Key: abc123

Server behavior:

If key is new → process request
If key already exists → return previous result

This guarantees single execution.

How Idempotency Works Internally

Flow:

Client generates unique key
Sends request with key
Server checks database/cache for key
If key exists → return stored response
If not exists → process request
Store key and response
Return response

Go Implementation Example

Let’s implement idempotent payment API using Go.

Database Table

idempotency_keys table:

key (primary key)
response
created_at

Go Example (Basic Version)

type IdempotencyRecord struct {
    Key      string
    Response string
}

Handler Implementation

func PaymentHandler(w http.ResponseWriter, r *http.Request) {

    key := r.Header.Get("Idempotency-Key")

    if key == "" {
        http.Error(w, "Idempotency-Key required", http.StatusBadRequest)
        return
    }

    // Check if key exists
    record, exists := getIdempotencyRecord(key)

    if exists {
        w.Header().Set("Content-Type", "application/json")
        w.Write([]byte(record.Response))
        return
    }

    // Process payment
    paymentID := processPayment()

    response := fmt.Sprintf(`{"payment_id": "%s"}`, paymentID)

    // Store key and response
    saveIdempotencyRecord(key, response)

    w.Header().Set("Content-Type", "application/json")
    w.Write([]byte(response))
}

Example Flow

First request:

POST /payments
Idempotency-Key: abc123

Response:
{
  "payment_id": "pay_001"
}

Retry request:

POST /payments
Idempotency-Key: abc123

Response returned from storage:

{
  "payment_id": "pay_001"
}

No duplicate payment created.

Production Implementation Using Redis (Recommended)

Redis is ideal because:

Extremely fast
Supports expiration (TTL)
Perfect for temporary idempotency storage

Redis Example in Go

func PaymentHandler(w http.ResponseWriter, r *http.Request) {

    key := r.Header.Get("Idempotency-Key")

    val, err := redisClient.Get(ctx, key).Result()

    if err == nil {
        w.Write([]byte(val))
        return
    }

    paymentID := processPayment()

    response := fmt.Sprintf(`{"payment_id": "%s"}`, paymentID)

    redisClient.Set(ctx, key, response, time.Hour*24)

    w.Write([]byte(response))
}

Important: Handle Race Conditions

Two requests may arrive simultaneously with same key.

Solution: Use atomic operations.

Redis example:

SET key value NX

NX = set only if not exists

Important Best Practice: Store Full Response

Do not just store key.

Store:

status code
response body
timestamp

Because retry must return exact same response.

Example Database Schema (PostgreSQL)

CREATE TABLE idempotency_keys (
    key TEXT PRIMARY KEY,
    response JSONB,
    status_code INT,
    created_at TIMESTAMP DEFAULT NOW()
);

Primary key ensures uniqueness.

Real-World Systems That Use Idempotency

Critical systems use idempotency extensively:

Payment APIs
Order creation APIs
Financial transactions
Booking systems
Wallet transfers
Stripe payments
Banking APIs

Without idempotency, financial systems would break.

Common Mistake Developers Make

❌ Using retry without idempotency

retry 3 times on failure

This multiplies side effects.

Example:

Retry logic: 3 times
Result: 3 payments

Dangerous bug.

Idempotency vs Duplicate Prevention Using Unique Constraints

Example:

UNIQUE(user_id, order_id)

This prevents duplicates at DB level.

But idempotency is better because:

Works at API level
Handles retries cleanly
Returns same response

Best approach: use BOTH.

When Should You Use Idempotency?

Use idempotency for operations that create side effects:

Payment creation
Order creation
Wallet transfer
Booking
Resource creation

Not required for:

GET requests
Read-only operations

How Client Should Generate Idempotency Key

Use UUID:

Example:

550e8400-e29b-41d4-a716-446655440000

Go example:

uuid.New().String()

Unique per operation.

Idempotency Key Expiration Strategy

Keys should expire after some time.

Common TTL:

24 hours
48 hours
7 days (depending on business need)

Redis makes expiration easy.

Example Architecture

Client → API Gateway → Service → Redis → Database

Redis handles idempotency keys
Database handles actual data

Fast and reliable.

Real Production Scenario: Mobile Network Retry

Mobile user taps "Place Order"

Network slow → timeout
Client retries automatically

Without idempotency → duplicate orders

With idempotency → safe retry

Important Difference: Safe Retry vs Unsafe Retry

Unsafe retry:

POST /orders

Safe retry:

POST /orders
Idempotency-Key: unique-key

Idempotency vs Exactly-Once Execution

Exactly-once execution is impossible in distributed systems.

Idempotency provides practical solution.

It ensures same final state.

Best Practices Checklist

Always:

Use idempotency keys for POST APIs
Store keys in Redis or database
Store full response
Use expiration
Handle race conditions
Use UUID keys
Combine with database constraints

Key Takeaway

Retries are normal.

Duplicate side effects are dangerous.

Idempotency ensures your APIs remain safe, reliable, and production-ready.

It is not optional for critical APIs - it is essential.

Final Thought

If your API handles payments, orders, bookings, or financial transactions - idempotency is mandatory.

Without it, retries can silently corrupt your system.

With it, your APIs become reliable, predictable, and safe.

🚀 UUIDv4 vs UUIDv7 in PostgreSQL

Fazal Mansuri — Sun, 08 Feb 2026 16:40:01 +0000

Why Switching UUID Versions Can Boost Performance at Scale

Many teams choose UUIDs as primary keys to support distributed systems and avoid ID collisions.
But not all UUIDs are equal.

Some teams have seen 10×–50× performance improvements simply by switching from UUIDv4 to UUIDv7.

Sounds surprising?
Let’s break it down - step by step - with no hand-waving.

🎯 What This Blog Will Help You Decide

By the end, you’ll understand:

What UUIDv4 and UUIDv7 actually are
How PostgreSQL indexes work internally
Why random IDs hurt performance
Why UUIDv7 scales dramatically better
When you should (and shouldn’t) switch
How to benchmark this yourself

1️⃣ Quick Refresher: What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value designed to be globally unique.

Why developers use UUIDs:

Safe for distributed systems
Can be generated client-side
No central ID generator
Avoids ID collisions across services

PostgreSQL stores UUIDs efficiently (16 bytes), so UUIDs themselves are not slow.

👉 The problem is the insertion pattern, not the type.

2️⃣ UUIDv4 - Random by Design

How UUIDv4 Works

UUIDv4 is purely random (122 random bits).

Example:

9f1c0d3a-4b6e-4b8f-8f91-17e0a0c9a721
e2a31f8b-91f2-4df7-98cb-6e9fcae721aa
0d2c5f99-5d8c-4b6d-8a0e-2dbbfa17d441

Key properties:

No ordering
No timestamp
Completely scattered values

This randomness is great for uniqueness
…but terrible for database indexes.

3️⃣ UUIDv7 - Time-Ordered UUIDs

UUIDv7 is a newer standard designed specifically for modern databases.

How UUIDv7 Works

UUIDv7 combines:

A timestamp (milliseconds) in the most significant bits
Random bits for uniqueness

Example (simplified):

018f3b3a-9b5c-7d12-bc01-9a2cfe123456
018f3b3a-9b5d-7f44-a231-acde441298ab
018f3b3a-9b5e-82a1-9d22-acde112341aa

Key properties:

Mostly increasing over time
Still globally unique
Still safe for distributed systems

👉 This ordering changes everything.

4️⃣ How PostgreSQL Stores and Indexes Data (Critical Part)

PostgreSQL Table Storage

Rows are stored in a heap
Order in heap is not guaranteed

PostgreSQL Indexes

Primary keys use B-tree indexes by default.

5️⃣ What Is a B-Tree (In Simple Terms)

A B-tree:

Stores keys in sorted order
Is optimized for:
- Sequential inserts
- Range scans
- Cache-friendly access

Think of it like:

A well-organized book where new pages are best added at the end.

6️⃣ Why UUIDv4 Hurts PostgreSQL Performance

With UUIDv4:

Each new ID belongs somewhere random in the index
PostgreSQL must:
- Find the correct position
- Split pages frequently
- Rebalance the tree
- Touch random memory pages

Consequences:

Heavy page splits
Index fragmentation
Poor cache locality
Increased disk I/O
Slower inserts
Slower reads
Slower vacuum

This gets worse as the table grows.

7️⃣ Why UUIDv7 Is Fast

With UUIDv7:

New rows are mostly appended
Inserts hit the rightmost leaf page
Minimal page splits
Excellent cache locality
Sequential disk writes

This is very similar to:

BIGSERIAL
IDENTITY
Snowflake-style IDs

👉 PostgreSQL loves this pattern.

8️⃣ Why Teams See 10×–50× Improvements

At scale (millions of rows):

Metric	UUIDv4	UUIDv7
Insert latency	High	Low
Index size	Large	Smaller
Cache efficiency	Poor	Excellent
Page splits	Frequent	Rare
Vacuum cost	High	Lower

⚠️ Important note:

50× is workload-dependent
Typical gains are 5×–20×
Still very significant

9️⃣ Hands-On Benchmark (You Can Try This)

Table Setup

CREATE TABLE test_uuid_v4 (
  id UUID PRIMARY KEY,
  data TEXT
);

CREATE TABLE test_uuid_v7 (
  id UUID PRIMARY KEY,
  data TEXT
);

Insert UUIDv4

INSERT INTO test_uuid_v4
SELECT gen_random_uuid(), 'data'
FROM generate_series(1, 1000000);

Insert UUIDv7 (Postgres 16+ or extension)

INSERT INTO test_uuid_v7
SELECT uuidv7(), 'data'
FROM generate_series(1, 1000000);

UUIDv7 generation requires Postgres 18 (uuidv7()) or an extension such as pg_uuidv7 in earlier versions.

Observe:

Insert time
Index size
CPU usage
Disk writes

You’ll see:

UUIDv7 inserts are dramatically smoother
Index size is smaller
Less I/O pressure

🔍 Why This Matters in Real Systems

Backend Impact

Faster writes
Better read performance
Healthier indexes
Lower infrastructure cost

Frontend Impact

IDs sort naturally by creation time
Easier pagination
Better caching behavior
Cleaner URLs

⚠️ When UUIDv7 Is NOT the Right Choice

Be honest and balanced:

If you need fully random IDs
If timestamp leakage is a concern
If your dataset is small
If sequential IDs are unacceptable

UUIDv7 is a performance trade-off, not magic.

🏁 Final Thoughts

This performance boost isn’t accidental — it’s how databases work.

The takeaway:

PostgreSQL B-trees love ordered inserts
UUIDv4 is random → bad at scale
UUIDv7 is time-ordered → excellent at scale
Schema design decisions matter more than hardware

Choosing the right ID strategy early can save years of performance tuning later.

💬 Have you used UUIDv4 in production and faced scaling issues?
Or already switched to UUIDv7?

Let’s discuss — real-world experiences help everyone.

⚠️ JavaScript Precision Loss with Large Numbers - The silent bug that breaks applications without error

Fazal Mansuri — Thu, 25 Dec 2025 11:52:48 +0000

Imagine this scenario:

Backend API returns a perfectly correct number
Network tab shows the correct value
No errors, no warnings
But your frontend logic behaves incorrectly

Hours of debugging later…
You realize the number changed automatically 😨

Welcome to JavaScript precision loss - one of the most dangerous silent bugs in web development.

This blog explains:

❓ Why this happens
💥 How it silently breaks applications
🔍 How to detect it
🛠 How to fix it (frontend & backend)
🧠 What both frontend and backend developers must know

🧠 The Root Cause: JavaScript Number Limit

JavaScript has only one numeric type:

Number

Under the hood, it uses IEEE-754 double-precision floating-point format.

That means JavaScript can safely represent integers only up to:

Number.MAX_SAFE_INTEGER
// 9007199254740991
// which is 2^53 - 1

Anything greater than this loses precision.

🚨 The Problem in Real APIs

Example API response (from backend):

{
  "transactionId": 9007199254740993
}

This value is valid, correct and often used for:

Database IDs
Transaction numbers
Order references
Snowflake IDs
Big integers from other systems

🔍 What You See in the Browser

🟢 Network → Response tab

{
  "transactionId": 9007199254740993
}

Looks perfect ✔️

🔴 Network → Preview tab (parsed by JS)

{
  transactionId: 9007199254740992
}

💥 Boom - value changed silently

No error
No warning
Just wrong data

😱 The Shocking Proof

Try this in the browser console:

9007199254740993 === 9007199254740992

👉 Result:

true

Yes. Two different numbers are considered equal.

That’s how dangerous this is.

🔥 Why This Is So Dangerous

This bug:

❌ Does NOT throw errors
❌ Does NOT break the UI immediately
❌ Does NOT show warnings

But it can:

Break ID-based logic
Send wrong IDs in the next API call
Fail updates / deletes silently
Corrupt data flows
Cause production-only bugs

And debugging becomes a nightmare because:

“The backend sent the correct value.”

Which is true - but irrelevant.

🔄 Where It Breaks Exactly

The precision loss happens during:

JSON.parse()

JavaScript parses JSON numbers into Number, and the precision is already lost at parse time.

By the time your code runs:

response.data.transactionId

The damage is already done.

👨‍💻 Backend Developers: This Is Also Your Responsibility

If your API schema includes:

IDs
Counters
Financial values
Any number that may exceed 2^53 - 1

❌ Returning them as JSON numbers is unsafe.

✅ Best Backend Practice

Return large numeric identifiers as strings:

{
  "transactionId": "9007199254740993"
}

This avoids precision loss entirely.

🧑‍💻 Frontend Developers: What If Backend Can’t Change?

Sometimes:

API is legacy
Schema cannot be changed
Third-party API returns big numbers

You still need a solution.

🛠 The Solution: `json-bigint`

json-bigint is a library that parses JSON without losing precision.

Install:

npm install json-bigint

Usage:

import JSONbig from 'json-bigint';

const response = JSONbig.parse(apiResponseText);

Now:

Large numbers are preserved
You can handle them safely
No silent corruption

You can choose:

BigInt
String representation
Custom handling logic

⚠️ Important Things to Remember

1️⃣ BigInt is NOT JSON-serializable

You must convert it before sending back to APIs.

2️⃣ Mixing Number & BigInt throws errors

Be consistent in comparisons and calculations.

3️⃣ IDs ≠ numbers

Treat IDs as identifiers, not math values.

🧪 How to Debug This Faster Next Time

If you suspect precision issues:

Check Network → Response
Compare with Network → Preview
Log raw response text
Compare values with strict equality
Check against Number.MAX_SAFE_INTEGER

This can save hours of debugging.

🏁 Final Thoughts

This bug is dangerous because it:

Looks harmless
Produces no errors
Corrupts data silently

Once you know it, you’ll never forget it.

Key Takeaways:

JavaScript numbers have limits
APIs must respect client constraints
Large IDs should be strings
Silent bugs are the most expensive bugs

If this post helped you learn something new, you’re already ahead of many developers.

💬 Have you ever faced a bug where everything “looked correct” but wasn’t?
Drop your experience - let’s learn from each other.

🚨 Memory Leaks in JavaScript & React - The Hidden Enemy

Fazal Mansuri — Sun, 14 Dec 2025 14:07:11 +0000

Memory leaks are tricky. You don’t see them immediately. Your UI works fine… until it doesn’t.
A few minutes, hours, or days later -

❌ the app becomes slow
❌ scrolling lags
❌ typing delays
❌ CPU usage spikes
❌ mobile devices heat up or crash

And the worst part?
The bug is invisible. No errors. No warnings. Nothing in the console.

This blog will reveal exactly why memory leaks happen in JavaScript & React, how to avoid them, how to debug them, and real mistakes developers make in production.

Let’s dive in 👇

🧠 1. What Is a Memory Leak?

A memory leak happens when your program keeps holding onto memory it no longer needs, preventing the browser from freeing it.
JS uses automatic garbage collection - but GC can only help if memory becomes unreachable.

If something still references that memory → leak.

🔥 2. Why Memory Leaks Happen in JavaScript

JavaScript leaks commonly come from:

1️⃣ Global variables

window.cache = {};

Never cleared → stored forever.

2️⃣ Closures storing unnecessary data

function heavy() {
  const big = new Array(1_000_000).fill("data");
  return () => console.log(big.length);
}

The closure keeps big alive.

3️⃣ Event listeners not removed

window.addEventListener("scroll", handler);
// never removed → stays in memory

4️⃣ Timers not cleared

setInterval(() => ..., 1000);
// still running even when component unmounted

5️⃣ DOM references stored in JS

const elems = [];
elems.push(document.getElementById("box"));
// Even if 'box' is removed from DOM, elems still holds reference → leak

⚛️ 3. Memory Leaks in React - Real Reasons They Happen

React helps prevent leaks…
…but leaks still happen when side effects run incorrectly.

Here are the most common sources:

🧩 3.1 Not cleaning up useEffect

❌ Leak example:

useEffect(() => {
  const id = setInterval(() => {
    console.log("running...");
  }, 1000);
}, []);

After component unmount → interval continues → leak.

✅ Fix:

useEffect(() => {
  const id = setInterval(() => {
    console.log("running...");
  }, 1000);

  // Cleanup: clear interval when component unmounts
  return () => clearInterval(id);
}, []);

🧩 3.2 Event listeners inside components

❌ Leak:

useEffect(() => {
  window.addEventListener("resize", handleResize);
}, []);

✅ Fix:

useEffect(() => {
  window.addEventListener("resize", handleResize);

  return () => window.removeEventListener("resize", handleResize);
}, []);

🧩 3.3 Async calls setting state after unmount

This is one of the MOST common leaks.

❌ Example:

useEffect(() => {
  fetch("/api/user")
    .then(res => res.json())
    .then(data => setUser(data)); 
}, []);

If the user navigates away →
React tries to update state on an unmounted component → memory leak + warning.

✅ Fix:

useEffect(() => {
  const controller = new AbortController();

  fetch("/api/user", { signal: controller.signal })
    .then(res => res.json())
    .then(data => setUser(data))
    .catch(err => {
      if (err.name !== 'AbortError') {
        console.error(err);
      }
    });

  return () => controller.abort();
}, []);

🧩 3.4 Huge arrays stored in state

React re-renders + stores stale copies.

❌ Storing large datasets in state
❌ Duplicating arrays on every update
❌ Logging huge objects inside useEffect

🔧 Fix:

Use pagination
Use memoization (useMemo) for expensive computations
Avoid storing raw API responses if unnecessary

🧩 3.5 Memory Leaks with React Strict Mode

React Strict Mode intentionally runs effects twice in development.
If cleanup logic is wrong → leaks appear in dev only.
⚠️ This doesn't happen in production, but fixing cleanup issues prevents real leaks.

🧪 4. Debugging Memory Leaks - Chrome DevTools (Simplest Guide)

This is the part devs struggle with.
Here is a beginner-friendly flow:

Step 1: Open Performance Monitor

Chrome → More Tools → Performance Monitor

Track:

JS Heap Size
DOM Nodes
Event Listeners

If these numbers keep increasing → leak.

Step 2: Take a Heap Snapshot

DevTools → Memory tab → Take Heap Snapshot

Then repeat after performing interactions.

Look for:

Detached HTML elements
Large arrays
Retained closures
Growing listeners

Step 3: Check Event Listeners

DevTools → Elements → Event Listeners

If the number keeps increasing on rerender → leak.

🛡 5. Preventing Memory Leaks - Best Practices

✔ Always clean up useEffect

✔ Avoid storing huge data in state

✔ Use paginated API responses

✔ Use AbortController to cancel fetch

✔ Throttle expensive events

✔ Use profiling tools regularly

🧨 6. Real-World Example - A Leak That Happened in Production

A dashboard had multiple charts
Each chart added a resize listener
Rerender recreated listeners
Old listeners remained
50+ listeners running simultaneously
Browser froze after 10 minutes

Fix: cleanup logic in useEffect + throttling resize events.

🏁 Final Thoughts

Memory leaks are scary because you don’t notice them immediately - but the impact is real.
React apps slow down, mobile users suffer, and debugging becomes painful.

But the good news?

👉 Once you understand how leaks happen
👉 And how to avoid them
👉 You can prevent 95% of them permanently

Your UI becomes faster, cleaner, smoother - and much easier to maintain.

⚛️ Controlled vs Uncontrolled Components in React – A Deep Dive

Fazal Mansuri — Sun, 16 Nov 2025 09:22:37 +0000

When building forms in React, you’ll inevitably come across controlled and uncontrolled components.
At first glance, they look similar — both accept user input and manage form data.
But how they manage that data under the hood can significantly impact performance, maintainability and UX.

In this blog, let’s break down the difference, see them in action, explore real-world issues (like cursor position and undo/redo bugs), and understand when to use each.

🧠 What Are Controlled Components?

In controlled components, React state is the single source of truth.
That means every keystroke or change updates the component’s state and that state determines what’s rendered.

Example:

import { useState } from "react";

function ControlledInput() {
  const [name, setName] = useState("");

  return (
    <input
      value={name}
      onChange={(e) => setName(e.target.value)}
      placeholder="Type your name"
    />
  );
}

Here, the <input> value is fully controlled by React via the name state.
Each keystroke triggers setName(), re-rendering the component with the updated value.

✅ Pros

Easy to validate or transform input on change.
Centralized state makes debugging and unit testing easier.
Integrates seamlessly with complex UIs or form libraries (Formik, React Hook Form).

⚠️ Cons

Frequent re-renders can impact performance in large forms.
Need to carefully manage performance and input lag.
Cursor position bugs can occur with advanced state management.

🧩 What Are Uncontrolled Components?

In uncontrolled components, the DOM maintains its own state — React just references it.
You don’t handle every keystroke; instead, you access the value when needed.

Example:

import { useRef } from "react";

function UncontrolledInput() {
  const inputRef = useRef();

  const handleSubmit = () => {
    alert(`Input value: ${inputRef.current.value}`);
  };

  return (
    <>
      <input ref={inputRef} placeholder="Type your name" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

✅ Pros

Better performance for simple forms.
Minimal React re-renders.
Perfect when you just need the final value.

⚠️ Cons

Harder to validate or modify values dynamically.
Not ideal when input data must always reflect application state.

⚔️ Controlled vs Uncontrolled: Key Differences

Feature	Controlled	Uncontrolled
Data Source	React State	DOM (via refs)
Performance	May re-render often	Faster for simple inputs
Validation	Easy to handle dynamically	Requires manual check
Use Case	Complex, validated forms	Simple or performance-critical inputs

⚡ Valtio & Controlled Inputs: Why Cursor Jumps Happen

When you use a state library like Valtio in a React controlled input, you might encounter this issue: you edit text in the middle of the input, but the cursor jumps to the end. This frustrates users and breaks the typing experience.

🔍 What’s going on?

By default, Valtio batches updates before triggering re-renders. The documentation states:

“By default, state mutations are batched before triggering re-render. Sometimes, we want to disable the batching.”
Because of this batching behavior, when you type and update the proxy state, multiple changes may be queued and then re-rendered in one go. During that delay, the browser loses context of the input cursor position, so after render the input’s value is applied and the cursor jumps to the end.

✅ The fix: { sync: true }

Valtio provides the option to disable batching for specific use-cases like inputs:

const snap = useSnapshot(state, { sync: true });

With sync: true, updates go through immediately rather than being deferred/batched. This keeps the input cursor where the user expects it.

⚠️ Trade-off:

Using sync: true disables batching optimizations, which can reduce render efficiency in large/complex components. Therefore:

Use sync: true only in input fields where cursor behaviour matters.
Avoid it for general state where performance is more important than instantaneous update.

🔁 Undo/Redo (Cmd+Z / Cmd+Shift+Z) in Controlled Components

Another subtle but important issue:
Undo (Cmd+Z) and Redo (Cmd+Shift+Z) might not work as expected in controlled inputs.

Why?
Because React replaces the entire value on every keystroke rather than letting the browser handle native input history.

This means the browser sometimes loses the input undo stack, especially if re-renders happen between updates.

🧪 What to do:

Test undo/redo behavior in all input fields before handing over to QA.
If using a state library or custom hooks, check whether it maintains the input history properly.
In cases where it fails and browser-native undo is critical (e.g., long text editors), consider using uncontrolled inputs or controlled wrappers that debounce updates.

🧰 Best Practices for React Forms

✅ Use controlled inputs when you need validation, dynamic control or shared state.
✅ Use uncontrolled inputs when performance and simplicity matter.
✅ For state libraries like Valtio, test cursor and undo behaviors thoroughly.
✅ Avoid unnecessary re-renders – use React.memo, useCallback or split components.
✅ Always test form UX — typing, cursor and undo/redo should feel native and fluid.

🎯 Final Thoughts

Controlled vs Uncontrolled Components seem like a small React concept, but they can deeply impact user experience, especially in complex form-heavy applications.

💡 Understanding these nuances (like cursor handling, undo/redo, and batching) helps you ship smoother, bug-free UIs that feel professional and reliable.

🚀 Whether you use plain React or libraries like Valtio, always test the real typing experience — that’s where users feel the difference.

💬 Have you ever faced cursor or undo issues in your React forms? Drop your experience or workaround below — let’s learn together! 👇

🚀 Mastering NestJS Concepts: Decorators, Dependency Injection, DTOs & More

Fazal Mansuri — Sat, 04 Oct 2025 08:43:56 +0000

NestJS is one of the most popular Node.js frameworks, combining TypeScript, OOP principles and modular design. It provides powerful tools like decorators, dependency injection and interceptors, which simplify building scalable applications.

In this blog, we’ll explore some core concepts of NestJS and tackle a real-world issue developers often face with DTOs and getters.

1️⃣ What Are Decorators in NestJS?

Decorators are metadata annotations that NestJS uses to add behavior to classes, methods and properties.

Examples:

@Controller() → Marks a class as a controller.
@Get(), @Post() → Define route handlers.
@Injectable() → Marks a class as available for dependency injection.

➡️ Best practice: Always use NestJS decorators instead of manually wiring routes or dependencies - it keeps code clean and testable.

2️⃣ Dependency Injection (DI) in NestJS

Dependency Injection is a design pattern where objects (services) are injected into a class instead of being created manually.

Example:

@Injectable()
export class UserService {
  findAll() {
    return ['user1', 'user2'];
  }
}

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Get()
  getUsers() {
    return this.userService.findAll();
  }
}

Here, UserService is automatically injected into UserController.

➡️ Why it matters?

Makes testing easier (you can mock dependencies).
Encourages loose coupling.
Simplifies large codebases.

Think about ordering pizza 🍕. You don’t grow the wheat, make the cheese and cook the pizza yourself every time - instead, you depend on a pizza shop to give it to you.
That’s Dependency Injection in software. Instead of a class creating everything it needs by itself, NestJS provides the needed things (dependencies) for you.

3️⃣ DTOs, Serialization & the Getter Issue

When working with DTOs (Data Transfer Objects) in NestJS, you often want to control what fields are returned in API responses. This is where class-transformer decorators like @Expose() and @Exclude() come in.

🔹 `@Expose()`

Marks a property (or getter) to be included in the serialized response.

export class UserDto {
  @Expose()
  id: number;

  @Expose()
  name: string;
}

➡ Only id and name will be serialized if you enable ClassSerializerInterceptor.

In NestJS, the ClassSerializerInterceptor cleans up API responses by hiding or exposing only the properties you mark (e.g., using @Exclude() or @Expose()). It’s mainly used to prevent sensitive fields like passwords from being sent back in responses.

🔹 `@Exclude()`

Removes sensitive/internal fields from the response.

export class UserDto {
  id: number;

  @Exclude()
  password: string;
}

➡ password will never appear in the response.

👉 Best practice: Use @Exclude() on class level, then selectively @Expose() only the fields you want returned.

⚠️ A Real-World Getter Issue

Imagine you want to dynamically compute a field. For example, a FolderDto that returns a folder type based on internal conditions:

export class FolderDto {
  isSpecial: boolean;

  @Expose()
  get type(): string {
    return this.isSpecial ? 'special' : 'default';
  }
}

At first glance, this looks fine ✅.
But what if you later need to override type explicitly for certain cases?

dto.type = 'custom'; // ❌ Won’t work

➡ The response will still show the getter’s computed value, because NestJS serialization prioritizes getters over explicitly set fields.

✅ The Robust Solution: Backing Property + Setter

To handle both cases (computed and explicit), use a private backing property with a setter:

export class FolderDto {
  isSpecial: boolean;
  private _customType?: string;

  set customType(value: string) {
    this._customType = value;
  }

  @Expose()
  get type(): string {
    if (this._customType) return this._customType;

    return this.isSpecial ? 'special' : 'default';
  }
}

Now:

If you set dto.customType = "archive", the response will use "archive".
If you don’t set it, the getter’s logic (special/default) will apply.

👉 This approach is flexible and future-proof – you avoid being locked into only getter-based logic.

4️⃣ Other Useful NestJS Concepts & Best Practices

🔹 Pipes

Transform and validate input data automatically. Example: ValidationPipe for DTO validation.

🔹 Interceptors

Modify requests/responses, add logging, or handle caching. Example: ClassSerializerInterceptor to apply @Expose and @Exclude.

🔹 Guards

Control access with authorization logic (CanActivate). Example: AuthGuard for JWT.

🔹 Filters

Handle exceptions globally or locally. Example: HttpExceptionFilter.

🎯 Final Thoughts

NestJS offers powerful abstractions that make backend development faster, safer and more maintainable.

✅ Use decorators to keep code clean.
✅ Rely on dependency injection for flexibility.
✅ Understand @Expose() / @Exclude() to manage responses.
✅ Watch out for getter pitfalls—fix with setters and backing properties.

💡 By learning these patterns and best practices, you’ll avoid debugging headaches and build APIs that scale.

🌐 Understanding CORS (Cross-Origin Resource Sharing): A Complete Guide

Fazal Mansuri — Sat, 27 Sep 2025 08:49:19 +0000

🔎 What is CORS?

Cross-Origin Resource Sharing (CORS) is a browser security feature that controls how web applications request resources (APIs, images, fonts, etc.) from a different origin (domain, protocol or port).

👉 Example:

Your React frontend runs at http://localhost:3000.
Your Go API runs at http://localhost:8080.
When React fetches data from Go API → this is a cross-origin request.

Without proper CORS setup, the browser blocks the request for security reasons.

⚙️ How Does CORS Work?

CORS works via HTTP headers exchanged between the browser and server.

1. Simple Requests

Happen when:

Method is GET, POST or HEAD
Headers are only "safe" ones (Accept, Content-Type as application/x-www-form-urlencoded, multipart/form-data, text/plain)

👉 Example:

GET /api/products HTTP/1.1
Origin: http://example-frontend.com

Server Response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example-frontend.com

If the header matches → browser allows. Otherwise, request is blocked.

2. Preflight Requests

For non-simple requests (e.g., PUT, DELETE or custom headers), the browser sends a preflight request using OPTIONS.

What is Preflight Request?
Not all requests go directly to the server. Sometimes, the browser first asks:
"Hey server, is it safe if I send this request?" - This is called a preflight request.
A preflight request is an OPTIONS call that the browser automatically makes before the actual request, when:

The HTTP method is not simple (GET, POST, HEAD).

The request has custom headers (e.g., Authorization, X-Custom-Header).

The Content-Type is not "safe" (application/x-www-form-urlencoded, multipart/form-data, text/plain).

👉 Example:

OPTIONS /api/products HTTP/1.1
Origin: http://example-frontend.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

Server must respond with allowed methods/headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://example-frontend.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 3600

Then, the actual request (PUT/DELETE) is sent.

✅ Why is CORS Important?

Protects Users: Prevents malicious sites from sending requests to other sites using your credentials (Cross-Site Request Forgery protection).
Granular Control: You decide which origins, methods and headers are safe.
Modern Requirement: Any modern web app with frontend + backend on different domains needs correct CORS setup.

⚠️ Common Issues Caused by CORS

1️⃣ Blocked by CORS Policy (No 'Access-Control-Allow-Origin' header)

Server not configured to allow the frontend domain.

2️⃣ Credential Errors

Cookies or tokens require:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://myapp.com

❌ Note: * cannot be used when credentials are allowed.

3️⃣ Preflight Failures

Backend doesn’t respond correctly to OPTIONS.

4️⃣ Wildcard Misuse

Using Access-Control-Allow-Origin: * everywhere → insecure.

🛠️ Example: CORS in Go (Gin Framework)

import (
    "github.com/gin-gonic/gin"
    "github.com/gin-contrib/cors"
    "time"
)

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

    r.Use(cors.New(cors.Config{
        AllowOrigins:     []string{"http://localhost:3000", "https://myapp.com"},
        AllowMethods:     []string{"GET", "POST", "PUT", "DELETE"},
        AllowHeaders:     []string{"Origin", "Content-Type", "Authorization"},
        ExposeHeaders:    []string{"Content-Length"},
        AllowCredentials: true,
        MaxAge: 12 * time.Hour,
    }))

    r.GET("/api/products", func(c *gin.Context) {
        c.JSON(200, gin.H{"product": "Laptop"})
    })

    r.Run(":8080")
}

👉 This setup allows React (localhost:3000) or production frontend to call your Go API.

🌍 Real-World Examples

Frontend hosted on Netlify (https://myapp.netlify.app) calling backend on AWS EC2 (https://api.myapp.com).
Without CORS → browser blocks requests.
With proper CORS headers → smooth API calls.

🔒 Best Practices

✅ Always restrict origins → never * for sensitive APIs.
✅ For multiple environments (dev/staging/prod), configure env-specific origins.
✅ Handle preflight (OPTIONS) requests in backend properly.
✅ Use Access-Control-Max-Age to reduce repeated preflights.
✅ Avoid allowing unnecessary headers/methods.
✅ Never rely only on CORS for security → also use authentication & rate limiting.

📌 Latest Info & Trends

CORS in Fetch API:
fetch(url, { mode: "cors", credentials: "include" }) must match backend CORS setup.
Private Network Access (PNA):
Browsers now add extra preflights for requests to private networks (like http://192.168.x.x).
Proxies in Dev:
- React (create-react-app) uses proxy in package.json to bypass CORS in local dev.
- In production → must fix at backend.

🎯 Final Thoughts

CORS might look like a “weird error message” at first, but it’s one of the most important browser security features.

If your frontend talks to your backend (different domain/port), you must configure CORS properly — otherwise, users face blocked requests.

👉 The key takeaway:

Don’t just throw * in Access-Control-Allow-Origin.
Think carefully about which origins, headers and methods are safe.
Set it once, document it and avoid long debugging sessions.

🛡️ Content Security Policy (CSP): A Complete Guide for Developers

Fazal Mansuri — Sat, 30 Aug 2025 11:00:57 +0000

Security is one of the most critical aspects of modern web development. Even if your code is correct, attackers may exploit vulnerabilities like Cross-Site Scripting (XSS) or Clickjacking. That’s where Content Security Policy (CSP) comes in.

This blog covers:
✅ What CSP is & how it works
✅ All major directives (default-src, script-src, img-src, etc.) explained in detail
✅ Real-world examples
✅ Best practices & common pitfalls

Let’s dive in. 🔥

⚙️ What is CSP & Why Do We Need It?

Content Security Policy (CSP) is an HTTP response header that defines where browsers can load resources (scripts, images, styles, fonts, iframes, workers, etc.) from.
Its main purpose: prevent XSS attacks by restricting execution of malicious scripts.
Without CSP, if an attacker injects a script into your page, the browser executes it blindly. With CSP, you can whitelist only trusted domains, blocking everything else.

Example CSP header:

Content-Security-Policy: default-src 'self'; img-src https://cdn.example.com; script-src 'self' https://apis.google.com;

This means:

By default, only load resources from the same origin ('self').
Allow images from cdn.example.com.
Allow scripts from self and Google APIs.

⚠️ Important:
If default-src is missing, everything is allowed, weakening your CSP.

📌 Important Directives

Here’s a breakdown of commonly used CSP directives:

🔑 `default-src`

The fallback for all other directives (if they are not explicitly defined).

Content-Security-Policy: default-src 'self';

If script-src or style-src is missing, browsers fall back to default-src. ✅

📜 `script-src`

Defines where JavaScript can be loaded from.

Content-Security-Policy: script-src 'self' https://apis.google.com;

Special values:
- 'self': allow only current domain
- 'unsafe-eval': allow eval() usage (⚠️ dangerous)
- 'unsafe-inline': allow inline scripts (⚠️ not recommended)

Better options:

Nonce → Random value per request:

<script nonce="abc123">console.log("Safe!");</script>

With CSP:

Content-Security-Policy: script-src 'self' 'nonce-abc123';

Hash → Allow only exact inline script:

<script>alert("hello")</script>

With CSP:

Content-Security-Policy: script-src 'self' 'sha256-XYZhashHere...';

✅ Nonce & Hash are safer than 'unsafe-inline'.

🎨 `style-src`

Controls where CSS can be loaded from.

Content-Security-Policy: style-src 'self' https://fonts.googleapis.com;

⚠️ Using 'unsafe-inline' allows inline styles → risky.
🔑 Instead:

Use nonce or hashes for dynamic styles.
Example:

  <style nonce="abc123">.btn { color: red; }</style>

🖼️ `img-src`

Defines allowed image sources.

Content-Security-Policy: img-src 'self' https://cdn.example.com data:;

👉 data: allows base64-encoded images.

📄 `font-src`

Controls allowed font sources.

Content-Security-Policy: font-src 'self' https://fonts.gstatic.com;

🔗 `connect-src`

Defines where AJAX/fetch/WebSocket connections can be made.

Content-Security-Policy: connect-src 'self' https://api.example.com;

🎵 `media-src`

Specifies allowed sources for <audio> and <video>.

Content-Security-Policy: media-src 'self' https://media.example.com;

🏗️ `frame-src` vs `frame-ancestors`

frame-src: Controls what your app can embed in an <iframe>.

  Content-Security-Policy: frame-src https://www.youtube.com;

frame-ancestors: Controls who can embed your site.

  Content-Security-Policy: frame-ancestors 'none';

✅ Use frame-ancestors to prevent clickjacking.

🧩 `worker-src`

Defines allowed sources for Web Workers & Service Workers.

Web Workers: Run scripts in a separate thread (background tasks).
Service Workers: Proxy requests for offline support / caching.

Content-Security-Policy: worker-src 'self' https://cdn.example.com;

📂 `object-src`

Restricts plugins like Flash/Silverlight (legacy). Best to set 'none'.

Content-Security-Policy: object-src 'none';

📝 Reporting with CSP

Instead of enforcing, you can test with reporting only:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;

This way, violations are logged but not blocked. Useful before rollout.

💡 Real-World Example

Imagine your webapp loads:

Scripts from your domain + Google APIs
Styles from your domain + Google Fonts
Images from CDN

CSP could look like:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://cdn.example.com; connect-src 'self' https://api.myapp.com; object-src 'none'; frame-ancestors 'none'

This protects you from attackers injecting malicious scripts/images from untrusted domains.

🚨 Common CSP Issues Developers Face

❌ Images not loading → Forgot img-src domain.
❌ Fonts breaking → Missing font-src.
❌ Videos not playing → media-src missing.
❌ API calls failing → Missing connect-src.
❌ App not embeddable → Strict frame-ancestors.

👉 If your frontend/backend look fine but still break, check CSP first.

✅ Best Practices

Always define a strict default-src.
Avoid 'unsafe-inline' and 'unsafe-eval' unless absolutely necessary – use nonces or hashes.
Use 'self' wherever possible.
Test with Content-Security-Policy-Report-Only before enforcing.

📌 Conclusion

CSP is not just another header—it’s a powerful security shield 🛡️ for your apps.
The right configuration prevents XSS, clickjacking, and data injection while keeping performance intact.

👉 The bottom line: CSP = Control + Security + Peace of Mind.

🛡️ Rate Limiting in Web Applications

Fazal Mansuri — Sun, 24 Aug 2025 11:25:42 +0000

In today’s API-driven world, applications face thousands—or even millions—of requests every day. While high traffic is great, it can also create challenges:

🔒 Security risks (brute force, DDoS attacks)
⚖️ Fair usage enforcement (avoid abuse of free tiers)
🚀 Performance stability (prevent one user from hogging resources)

This is where Rate Limiting comes in.

Rate limiting ensures a user, IP or client can only make a defined number of requests within a specific time window. It’s a cornerstone of modern, scalable APIs.

🧩 Why Do We Need Rate Limiting?

🔐 Security → Protect against brute force login attempts, API scraping, and DDoS attacks.
⚖️ Fair Usage → Prevent abuse of APIs, especially for freemium services.
🚀 Performance → Ensure backend resources are shared fairly among all users.
💰 Cost Control → Reduce infrastructure bills by blocking excessive or abusive requests.

⚙️ Common Rate Limiting Algorithms

1️⃣ Token Bucket

Requests are allowed if tokens are available.
Tokens refill at a fixed rate.
Commonly used (flexible + efficient).

🔧 Example: Allow 10 requests per second. If unused, tokens accumulate up to a max limit (burst handling).

2️⃣ Leaky Bucket

Works like water dripping from a bucket at a fixed rate.
Bursts are smoothed out.
Useful for evenly distributing traffic.

3️⃣ Fixed Window Counter

Count requests in a fixed time window (e.g., 100 requests per minute).
❌ Edge case: allows bursts at window boundaries.

4️⃣ Sliding Window Log

Keeps timestamps of requests.
Precise but memory-heavy for large scale.

5️⃣ Sliding Window Counter

Hybrid approach: averages counts across windows.
More accurate than fixed window, less heavy than logs.

🔧 Implementing Rate Limiting in Applications

Example in Go (Gin Framework)

package main

import (
    "github.com/gin-gonic/gin"
    "golang.org/x/time/rate"
    "net/http"
    "time"
)

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

    // Create a limiter: 5 requests/sec, burst up to 10
    limiter := rate.NewLimiter(5, 10)

    r.GET("/api", func(c *gin.Context) {
        if !limiter.Allow() {
            c.JSON(http.StatusTooManyRequests, gin.H{"error": "Too many requests"})
            return
        }
        c.JSON(http.StatusOK, gin.H{"message": "Request successful"})
    })

    r.Run(":8080")
}

✅ Each client is limited to 5 requests per second with a burst allowance of 10.

🚦 Rate Limiting with NGINX

NGINX can handle rate limiting at the web server or reverse proxy level, making it a powerful tool to protect your backend before requests hit your app.

⚙️ How It Works

NGINX uses two main directives:

limit_req_zone → Defines a shared memory zone to track requests (by IP or custom key).
limit_req → Applies the limit to endpoints.

🔧 Basic Example

http {
  # 1. Define rate limit zone (1 request/sec, burst 5)
  limit_req_zone $binary_remote_addr zone=api_limit:10m rate=1r/s;

  server {
    location /api/ {
      # 2. Apply rate limit
      limit_req zone=api_limit burst=5 nodelay;

      proxy_pass http://backend_service;
    }
  }
}

🔍 Explanation

Key: $binary_remote_addr → Track by client IP.
Rate: 1r/s → Allows 1 request per second per IP.
Burst: 5 → Short bursts up to 5 requests allowed.
nodelay: Burst requests are processed immediately.

✅ Advantages

Filters traffic before hitting your backend.
Can apply limits per endpoint (e.g., /login stricter than /products).
Lightweight & fast.

📊 Logs & Monitoring

Exceeded requests → logged as 503 (Service Unavailable).
Useful for tracking abuse & fine-tuning limits.

⚠️ Considerations

Avoid overly strict global limits (may block valid traffic).
Use $realip_remote_addr when behind a proxy/load balancer.
Always test before production rollout.

🔒 Best Practices for Rate Limiting

🎯 Apply stricter limits on sensitive endpoints (like /login).
🌍 Use different limits per client type (mobile app vs. server-to-server).
🧩 Combine server-level (NGINX/API Gateway) + app-level checks.
📊 Monitor logs & dashboards for blocked traffic trends.
🚀 Use distributed stores (Redis) for shared limits in multi-instance apps.

💡 Bonus Tips

✅ 429 Status Code: Always return HTTP 429 Too Many Requests with a helpful message.
✅ Retry-After Header: Tell clients when to retry. Example:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

✅ Graceful Degradation: Don’t just block—offer reduced functionality for non-critical requests.

🎯 Final Thoughts

Rate limiting is not just a performance tool—it’s a security guard, cost saver and reliability booster.

Whether you use algorithms in code, NGINX or API Gateways (Kong, Apigee, AWS API Gateway), implementing proper rate limiting ensures:

✔️ Fair usage
✔️ Secure endpoints
✔️ Scalable systems

🚀 The bottom line? Smart rate limiting makes APIs faster, safer, and fairer—for everyone.

💬 What approach do you use for rate limiting in your backend? Have you tried using Redis or NGINX rules? Let’s discuss in the comments!

⚡️ Caching Strategies for Web Apps: From Browser to Backend

Fazal Mansuri — Sun, 13 Jul 2025 07:28:46 +0000

Caching is one of the most powerful ways to improve application performance—reducing load times, server costs, and user frustration. Yet many developers treat caching as a “black box” or skip it due to fear of cache-related bugs.

In this blog, we will:
✅ Demystify caching: what it is and why it matters
✅ Explore frontend (browser) caching strategies
✅ Dive into backend and distributed caching with Go examples
✅ Cover Cache-Control headers, ETag, stale-while-revalidate
✅ Discuss common pitfalls and best practices

By the end, you’ll know how to confidently implement caching in your React frontend and Go backend to build scalable, fast, and efficient applications.

🚀 What is Caching?

Caching means storing data temporarily so future requests can be served faster without recomputing or refetching the same data repeatedly.

Think of it like preparing tea and storing it in a flask—you don’t need to reboil water each time you want to drink.

📈 Why Caching Matters

Speed: Return data faster to users.
Reduce Server Load: Avoid redundant computation or DB queries.
Improve Reliability: Serve cached responses when backend services are down.
Reduce Costs: Less compute = lower cloud bills.

🧩 Caching in the Frontend (Browser)

1️⃣ Browser Cache (HTTP Caching)

Browsers automatically cache assets (JS, CSS, images) and API responses based on HTTP headers.

Key Headers:

Cache-Control: Defines how long and under what conditions the browser can reuse the response.
ETag: Helps validate cached data; server sends a hash, and browser sends it back to check if the data changed.
Expires: Sets a hard expiration time for cache.
stale-while-revalidate: Allows serving stale content while revalidating in the background for a seamless UX.

Example:

Cache-Control: public, max-age=3600, stale-while-revalidate=600

✅ Use Case: Cache API GET responses for non-user-specific data (e.g., blog posts, product catalogs).

2️⃣ Client-Side Data Fetching Libraries

Libraries like React Query, SWR provide built-in caching for API calls.

Cache API responses in memory.
Background revalidation for fresh data.
Avoids unnecessary re-fetching on component re-mounts.

✅ Use for per-session data caching in React apps.

🗂️ Caching in the Backend

1️⃣ In-Memory Caching

Store frequently accessed data in memory for fast retrieval.

Examples: Golang’s sync.Map, groupcache.
Fastest but limited by server RAM and is not shared across instances.

✅ Use for small, frequently requested data (e.g., config, auth tokens).

2️⃣ Distributed Caching

Tools like Redis and Memcached provide a shared cache layer accessible across multiple servers.

Benefits:

Centralized cache for load-balanced apps.
Supports expiration policies.
Can handle large datasets.

🔹 Go Example: Using Redis for Caching

1. Install Redis client:

go get github.com/go-redis/redis/v8

2. Basic Usage:

rdb := redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

ctx := context.Background()

// Set cache
rdb.Set(ctx, "product_123", jsonData, time.Hour)

// Get cache
val, err := rdb.Get(ctx, "product_123").Result()
if err == redis.Nil {
    // Cache miss, fetch from DB
} else {
    // Cache hit, use val
}

⚖️ Cache Invalidation: The Hard Part

“There are only two hard things in Computer Science: cache invalidation and naming things.” – Phil Karlton

Whenever the underlying data changes, you need to ensure the cache is updated to avoid stale data.

Strategies:

✅ Time-based expiration (TTL):
Set a cache expiry time so data auto-expires after a fixed duration, ensuring old data clears automatically.

✅ Manual invalidation:
Manually clear or update cache entries whenever the underlying data changes to keep data fresh.

✅ Write-through caching:
Write data to both the cache and the database at the same time, ensuring consistency during reads.

✅ Cache busting:
Change cache keys (e.g., v1:product_123 → v2:product_123) when your data structure changes to avoid serving stale or incompatible data.

✅ Best Practices for Caching

Cache only GET requests; avoid caching POST unless explicitly designed.
Set reasonable TTLs to avoid stale data.
Monitor cache hit/miss rates to tune cache policies.
Be cautious caching user-specific or sensitive data.
Use cache versioning (v1:product_123) to manage structure changes.
Document what is cached, where, and why.

⚠️ Common Pitfalls

🚫 Caching sensitive user data publicly.
🚫 Forgetting to invalidate cache on data updates.
🚫 Over-caching dynamic endpoints, leading to stale or incorrect UI.

🔮 Future of Caching: CDN & Edge Caching

Content Delivery Networks (CDNs) like Cloudflare, AWS CloudFront, Vercel Edge cache data closer to the user.

Benefits:
✅ Lower latency.
✅ Offload origin server traffic.
✅ Built-in stale-while-revalidate strategies.

Using edge caching in modern React + Go apps can drastically improve performance globally.

🎯 Final Thoughts

Caching isn’t just an optimization; it’s essential for building scalable, reliable, and fast applications.

Whether it’s browser caching, React Query in the frontend, or Redis in the backend, knowing when and how to cache makes you a stronger developer.

💬 Have you implemented caching in your apps? What caching challenges have you faced? Let’s discuss in the comments!