DEV Community: Fazal Mansuri

📦 AI Context Engineering (Part 2): Tokens, Context Windows & Memory - Why More Context Isn't Always Better

Fazal Mansuri — Sun, 05 Jul 2026 06:23:35 +0000

In Part 1, we learned that building great AI applications isn't just about writing better prompts.

It's about providing the right context.

But that naturally leads to another question:

How much context can an AI actually understand?

If you've used ChatGPT, Claude, Gemini, Cursor or any AI coding assistant for a while, you've probably experienced something like this.

🤔 "Didn't I Already Tell You That?"

Imagine you're debugging a production issue with an AI assistant.

You start by explaining the architecture.

Then you share the API flow.

Then database schema.

Then logs.

Then stack traces.

After 30 minutes of conversation, you ask:

"So what's causing the bug?"

Instead of giving the answer, the AI responds:

"Could you share your database schema?"

You stare at the screen.

"I already did..."

Sometimes it even forgets details from earlier in the same conversation.

Naturally, people assume:

The AI has bad memory.
The model is unreliable.
The conversation is broken.

In reality, something completely different is happening.

You're running into one of the most important concepts in modern AI systems:

The Context Window.

Understanding this concept changes how you interact with AI—and more importantly, how you build AI-powered applications.

🧠 Before We Talk About Context Windows…

We first need to understand something much smaller.

Tokens.

Almost every AI provider mentions them.

Pricing is based on them.

Context windows are measured using them.

Yet many developers still think:

1 token = 1 word

That isn't true.

🔤 What Exactly Is a Token?

A token is the basic unit of text that an AI model processes.

Humans naturally read text as:

Characters
Words
Sentences

Large Language Models don't.

Before text reaches the model, it's converted into smaller pieces called tokens by a tokenizer.

The model never sees your original sentence.

It only sees a sequence of tokens.

Think of a tokenizer as a translator between humans and AI.

You write English
        ↓
Tokenizer
        ↓
Sequence of Tokens
        ↓
LLM

The tokenizer decides how text is split.

And that's why tokens aren't the same as words.

Tokens ≠ Words

This is probably the biggest misconception about LLMs.

Consider this sentence:

Hello World

You might expect:

2 words = 2 tokens

Sometimes that's true.

Sometimes it isn't.

Now consider:

internationalization

One word.

But depending on the tokenizer, it may be split into multiple tokens because the model has learned common sub-word patterns rather than every possible English word.

Similarly:

authentication
authorization
microservices

may also become multiple tokens.

The tokenizer isn't trying to understand grammar.

It's trying to represent text efficiently based on patterns it learned during training.

📦 Different Types of Content Produce Different Numbers of Tokens

One reason token counting surprises developers is that not all text is equal.

Take these examples.

Example 1 — Simple English

The server is running normally.

This is relatively efficient because it contains common words.

Example 2 — JSON

{
  "userId": 123,
  "isActive": true
}

Even though this looks short, punctuation, quotes, braces and field names also become tokens.

Example 3 — Source Code

if err != nil {
    return err
}

Programming languages introduce symbols, keywords, indentation and identifiers, all of which contribute to the token count.

Example 4 — URLs

https://example.com/api/v1/users/123

URLs often tokenize differently because of slashes, punctuation and path segments.

Example 5 — Emojis

🚀🔥🎉

Even emojis are tokenized.

Different models may tokenize the same emoji sequence differently.

💡 The Important Lesson

Tokens are not based on what humans consider words.

They're based on how the tokenizer breaks text into pieces.

That's why two pieces of text with the same number of characters can consume very different numbers of tokens.

🎯 Why Should Developers Care About Tokens?

Many developers only think about tokens when they receive an API bill.

In reality, tokens influence almost everything about an AI system.

They affect:

Cost
Latency
Context size
Response quality
Memory
Scalability

Every AI request starts with a token budget.

The more tokens you consume, the more work the model has to perform.

💰 Everything Consumes Tokens

Here's something many people don't realize.

When you send a request to an LLM, you're not paying only for your latest prompt.

The model processes everything included in the request.

That may include:

Content	Uses Tokens?
System Instructions	✅
User Prompt	✅
Conversation History	✅
Uploaded Documents	✅
Retrieved RAG Results	✅
Tool Outputs	✅
Function Call Results	✅
AI Response	✅

Even if you only typed:

Summarize this.

The model might actually receive thousands of tokens.

Imagine asking an AI coding assistant:

Why is this function failing?

Behind the scenes, the application might automatically include:

System instructions
Current source file
Nearby functions
Package imports
Build configuration
Previous conversation
Compiler errors

Your four-word prompt becomes a request containing thousands of tokens.

This is another example of Context Engineering in action.

🔄 Every New Request Starts Again

This surprises many engineers.

Suppose your conversation looks like this:

User:
Explain JWT Authentication.

Assistant:
...

User:
Can you show a Go example?

Assistant:
...

User:
Can you make it use middleware?

Many people imagine the model simply remembers everything internally.

That's not how most stateless LLM API interactions work.

For each new request, the application typically sends the conversation history (or a selected portion of it) again so the model has the necessary context to continue the conversation coherently.

Conceptually, it looks something like this:

Request 1

System Prompt
User Message

↓

LLM

------------------------

Request 2

System Prompt
Conversation History
New User Message

↓

LLM

------------------------

Request 3

System Prompt
Conversation History
Latest User Message

↓

LLM

As the conversation grows longer, more tokens are often included with each request unless the application trims, summarizes or otherwise manages the context.

This is one reason token usage can increase significantly during long conversations.

🪟 What Is a Context Window?

Now we can finally answer the question from the beginning.

If tokens are the building blocks…

Then what is the Context Window?

A context window is the maximum amount of information (measured in tokens) that a model can consider at one time while generating a response.

Think of it like a whiteboard.

Imagine you're solving a difficult problem with a teammate.

Everything written on the whiteboard is available to both of you.

You can read it.

Reference it.

Connect ideas.

Reason about it.

But the whiteboard isn't infinite.

Eventually, it fills up.

To continue working, you have two choices:

Erase older notes.
Replace them with a summary.

Large Language Models work in a very similar way.

The context window is that whiteboard.

Everything currently inside it is visible to the model while it generates its next response.

Everything outside it is invisible unless your application decides to bring it back.

📖 What's Actually Inside the Context Window?

One common misconception is that the context window contains only your prompt.

In reality, modern AI applications often build a much richer context before sending the request.

A simplified request might look like this:

System Instructions

↓

Conversation History

↓

Retrieved Knowledge (RAG)

↓

Uploaded Files

↓

Tool Results

↓

Current User Prompt

↓

LLM

Notice something interesting.

Your latest message may only be a tiny fraction of everything the model receives.

The application has already assembled the rest of the context behind the scenes.

This is why two AI tools using the same underlying model can produce very different answers.

The difference often isn't the model itself.

It's how effectively each application constructs the context before making the request.

🤔 Does a Bigger Context Window Always Mean Better AI?

At first glance, it sounds obvious.

If an AI model can process more information, shouldn't the answers always improve?

Not necessarily.

Imagine you're preparing for an interview.

Someone gives you:

Your resume
The job description
Company documentation
Engineering handbook
API documentation
Meeting notes
Internal wiki
Product roadmap
Last year's planning documents
Random Slack conversations

Could you answer the interview questions?

Probably.

Would all that information actually help?

Probably not.

In fact, it might make things worse because you'd spend time filtering out irrelevant information before focusing on what matters.

Large Language Models face a similar challenge.

A larger context window allows the model to see more information, but it doesn't mean every piece of that information is equally useful.

Good Context Engineering isn't about maximizing context.

It's about optimizing context.

🎯 More Context ≠ Better Context

One of the biggest mistakes in AI applications is thinking:

If some context helps,
more context must help even more.

That's rarely true.

Imagine building an AI coding assistant.

A developer asks:

Why is this API returning 500?

Option A:

Provide only:

The API handler
Relevant service
Error log

Option B:

Provide:

Entire repository
All dependencies
Every README
CI/CD configuration
Kubernetes manifests
Previous conversations
All database schemas

Technically, the model has more information.

Practically, you've introduced noise.

Finding the relevant signal becomes harder.

This is why mature AI systems spend significant effort deciding what not to include.

Context Engineering is often about removing information rather than adding it.

🔍 The "Lost in the Middle" Problem

Researchers have observed an interesting behavior in long-context language models.

When a prompt becomes very large, information buried in the middle of the context may receive less attention than information closer to the beginning or end.

This phenomenon is commonly referred to as the "Lost in the Middle" effect.

Imagine reading a 300-page document.

You usually remember:

The introduction
The conclusion

But details from page 147?

Much harder.

Language models can exhibit similar behavior under certain conditions.

This doesn't mean long-context models are ineffective.

It means that how information is organized inside the context matters, not just how much information is included.

🧠 Context Is NOT Memory

This is probably the biggest misconception about modern AI.

People often say:

"ChatGPT remembered what I told it last week."

What actually happened depends on the application.

It's important to distinguish between context and memory.

Context

Context is the information available only for the current request.

Once the request is complete, the model itself doesn't retain that context for future API calls.

Think of it as a whiteboard used during a meeting.

Erase the whiteboard and the discussion is gone.

Memory

Memory is information that an application intentionally stores and later reintroduces into future conversations.

For example:

You tell an AI assistant:

I primarily write Go and React.

The application might choose to save that preference.

Next week, when you ask:

Generate an API example.

The application retrieves your stored preference and injects it into the new request.

The model appears to "remember."

In reality, the application supplied that information again.

The memory lives in the application—not inside the language model itself.

🏗️ A Simple Mental Model

Think of an AI application as three separate components:

                User

                  │
                  ▼

      ┌─────────────────────┐
      │   Memory Store      │
      └─────────────────────┘
                  │
                  ▼
      ┌─────────────────────┐
      │ Context Builder     │
      │ - System Prompt     │
      │ - History           │
      │ - RAG Results       │
      │ - Tool Outputs      │
      └─────────────────────┘
                  │
                  ▼
      ┌─────────────────────┐
      │        LLM          │
      └─────────────────────┘

The LLM only sees the final assembled context.

It doesn't know where each piece of information came from.

💰 Why Tokens Matter for Cost and Performance

We've already learned that everything consumes tokens.

But token usage affects much more than pricing.

It also impacts:

Request latency
Throughput
Infrastructure cost
User experience

Consider these two requests.

Efficient Request

System Prompt

Relevant API documentation

Current User Question

Inefficient Request

System Prompt

Entire conversation

Complete codebase

Multiple PDFs

Large JSON payloads

Old logs

Current User Question

The second request requires the model to process significantly more information before generating a response.

Even if the answer only depends on a small portion of that data.

More tokens generally mean:

More computation
Higher latency
Higher cost

This is why production AI systems invest heavily in efficient context management.

⚙️ How Production AI Systems Manage Context

Well-designed AI applications rarely send everything they know to the model.

Instead, they carefully construct the context.

Some common strategies include:

✅ Retrieve Only What's Relevant

Instead of sending an entire knowledge base,

retrieve only the documents related to the user's question.

✅ Summarize Long Conversations

Rather than sending hundreds of previous messages,

summarize earlier parts while preserving important facts.

For example:

Instead of:

150 previous messages

Send:

Conversation Summary:

• User uses Go
• Building REST APIs
• Uses PostgreSQL
• Currently debugging authentication

Far fewer tokens.

Much easier for the model.

✅ Keep System Prompts Focused

System instructions should define behavior,

not contain an entire company handbook.

✅ Separate Long-Term Memory from Current Context

Store reusable preferences separately.

Retrieve them only when needed.

✅ Measure Token Usage

Don't optimize blindly.

Most AI SDKs expose token usage statistics.

Monitoring them helps identify unnecessary context and control costs.

🚫 Common Context Engineering Mistakes

Here are some patterns that often reduce AI quality rather than improve it.

❌ Dumping entire documents into every request

More information isn't automatically better.

❌ Sending the full conversation forever

Long conversations should be summarized or trimmed when appropriate.

❌ Treating memory as conversation history

They're different concepts.

❌ Ignoring token usage

Unexpected token growth often leads to higher costs and slower responses.

❌ Assuming bigger context windows solve everything

Context quality matters far more than context quantity.

🎯 Best Practices

If you're building AI-powered applications, keep these principles in mind:

✅ Send only the information required for the current task.

✅ Prefer relevant context over larger context.

✅ Separate memory from conversation history.

✅ Summarize older interactions instead of continuously expanding prompts.

✅ Monitor token usage in production.

✅ Design context deliberately instead of simply appending more text.

🏁 Final Thoughts

When people first start working with AI, they often focus on prompts.

Then they discover Context Engineering.

Eventually, they realize another important truth:

Not all context is equally valuable.

Modern AI systems succeed because they carefully decide:

What to include
What to exclude
What to summarize
What to retrieve
What to remember

That decision-making process is often more important than the prompt itself.

The best AI applications aren't the ones with the biggest context windows.

They're the ones that provide the right information at the right time.

And that's exactly what Context Engineering is about.

📌 Key Takeaways

Tokens are the fundamental units processed by language models—they are not the same as words.
Every request consumes tokens, including system prompts, conversation history, retrieved documents, tool outputs and the model's response.
A context window defines how much information a model can consider at once.
Larger context windows are useful, but more context doesn't automatically lead to better answers.
Context and memory are different: context exists for the current request, while memory is information intentionally stored and reintroduced by the application.
Effective Context Engineering is about sending relevant information, not all available information.
Good context management improves response quality, reduces costs and lowers latency.

🚀 Coming Up in Part 3

So far, we've answered:

What is Context Engineering?
What are tokens?
How do context windows work?
Why isn't bigger context always better?
What's the difference between context and memory?

But another important question remains:

Where does all this context actually come from?

How do AI applications automatically search documentation, query databases, call APIs, execute tools and decide what information should be sent to the model?

That's where concepts like Retrieval-Augmented Generation (RAG), Tool Calling, Model Context Protocol (MCP) and AI Agents come into the picture.

We'll break each of them down in Part 3 with practical examples and real-world engineering scenarios.

🧠 AI Context Engineering — Why Great AI Systems Need More Than Great Prompts (Part 1)

Fazal Mansuri — Sat, 27 Jun 2026 11:15:39 +0000

A couple of years ago, almost every AI discussion revolved around one thing:

Prompt Engineering.

People shared prompts like:

"Use this prompt to become a senior software engineer."
"Use this prompt to write perfect SQL."
"Use this prompt to generate production-ready code."

The assumption was simple:

Better prompt = Better AI output.

While prompts certainly matter, engineers building production AI systems quickly realized something important:

The prompt is only one piece of the puzzle.

Modern AI applications - whether it's ChatGPT, Claude, Cursor, GitHub Copilot or AI coding agents - don't rely on a single prompt.

They combine multiple sources of information before generating a response.

That broader discipline is known as Context Engineering.

And understanding it is becoming one of the most valuable skills for engineers building AI-powered products.

What Is Context Engineering?

Context Engineering is the practice of providing an AI model with the right information at the right time so it can generate accurate, relevant, and reliable responses.

Think of it this way:

Prompt Engineering asks:

"What should I ask the model?"

Context Engineering asks:

"What information should the model have before it answers?"

That difference might sound subtle.

In reality, it changes everything.

A Simple Analogy

Imagine you ask two developers the same question.

"How do I fix this production bug?"

Developer A

You only tell them:

"The application is broken."

Can they help?

Maybe.

But they'll probably ask dozens of follow-up questions.

Developer B

Instead, you provide:

Error logs
Stack trace
API request
Database query
Recent deployment
Service architecture

Now they're much more likely to identify the issue quickly.

Did they become smarter?

No.

You simply gave them better context.

Large Language Models work the same way.

Prompt vs Context

Suppose you ask an AI:

Write a SQL query to fetch active users.

That's a perfectly valid prompt.

But now imagine providing additional context:

Database: PostgreSQL

Tables:

users
- id
- email
- status
- created_at

Status can be:
ACTIVE
INACTIVE
BLOCKED

Return only active users created after January 1st, 2025.

The prompt itself barely changed.

What improved was the context.

And naturally, the quality of the output improves as well.

Why Prompt Engineering Alone Isn't Enough

Imagine building an AI customer support assistant.

If every user message is handled using only:

User:
Where is my order?

the model has no idea:

Which customer is asking
Which order they mean
Whether it has already been shipped
Previous conversations
Company refund policy

Without that information, the model can only guess.

Instead, production AI systems enrich the request with additional context before sending it to the model.

For example:

System Instructions

Customer Name

Previous Conversation

Order Status

Shipping Details

Refund Policy

Current User Question

The model now has everything it needs to generate a useful answer.

Notice something interesting:

The user's prompt didn't become dramatically better.

The available context did.

What Actually Forms the Context?

Many developers think context means:

"The text I type into ChatGPT."

That's only part of it.

In reality, the model usually receives much more information.

A typical request may include:

System instructions
User prompt
Conversation history
Retrieved documentation
Project files
Tool outputs
Function call results
Memory from previous interactions

All of this together forms the context.

The model doesn't distinguish whether information came from you, a database, or another tool.

It simply processes the complete context it receives.

A Real-World Example

Consider an AI coding assistant.

You ask:

Explain this function.

How does it know which function you're referring to?

It doesn't.

The IDE silently provides additional context such as:

The currently opened file
Surrounding code
Project structure
Imported packages
Programming language
Cursor position

You only typed four words.

Yet the model received thousands of tokens of additional information behind the scenes.

That's Context Engineering in action.

Another Example: ChatGPT

Suppose you ask:

Summarize this document.

What actually reaches the model?

Something closer to:

System Instructions

Conversation History

Uploaded PDF

User Prompt

Formatting Rules

Safety Instructions

Again, the prompt is only a small part of the overall request.

The Mental Shift

Many developers spend hours refining prompts like:

Act as a senior software engineer with 20 years of experience...

Sometimes it helps.

But often, providing the model with:

Better documentation
Relevant code
Correct API schemas
Business rules
Examples

produces significantly better results than endlessly tweaking the wording of the prompt.

The question changes from:

"How should I ask?"

to:

"What information is the model missing?"

That's the mindset of Context Engineering.

Common Misconceptions

❌ "A bigger prompt always gives better answers."

Not necessarily.

Adding irrelevant information can confuse the model.

Good context is relevant, accurate, and focused.

❌ "Prompt Engineering is no longer useful."

Prompt Engineering is still important.

A clear prompt helps the model understand the task.

Context Engineering simply expands the scope by ensuring the model also has the information required to perform that task well.

Think of prompt engineering as one part of the larger Context Engineering process.

❌ "Only AI engineers need to know this."

If you build software that integrates AI in any form—chatbots, coding assistants, document search, customer support, or internal tools—understanding how context influences responses will help you design more reliable systems.

Why This Matters More Than Ever

Modern AI applications are no longer just chat interfaces.

They're becoming agents that:

Read documents
Search knowledge bases
Execute tools
Call APIs
Generate code
Reason over project files

The quality of these systems depends less on writing a "magic prompt" and more on giving the model the right context.

And that's exactly what Context Engineering is about.

What's Coming in Part 2?

Now that we understand why context matters, another important question arises:

How much context should we provide?

Is more always better?

What are tokens?

What is a context window?

Why do AI tools sometimes forget earlier parts of a conversation?

And why can adding too much information actually reduce response quality?

We'll answer all of these in Part 2, where we'll explore:

Context Windows
Tokens
Conversation History
Memory
Why bigger context isn't always better
Practical strategies used by modern AI applications

Understanding these concepts will completely change how you think about interacting with—and building—AI systems.

Key Takeaways

Prompt Engineering and Context Engineering are related, but not the same.
Great AI systems rely on much more than the user's prompt.
Context includes system instructions, conversation history, retrieved information, tool outputs, and more.
Better context often improves AI responses more than endlessly refining prompts.
Thinking in terms of "What information is the model missing?" is the first step toward building effective AI-powered applications.

If you've ever wondered why the same prompt produces excellent results in one AI application and poor results in another, the answer often isn't the model itself.

It's the context behind the scenes.

See you in Part 2 👋

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

Fazal Mansuri — Sat, 06 Jun 2026 06:57:43 +0000

Most developers learn CSS specificity once.

They remember:

#id > .class > div

Then move on.

Until one day…

Everything looks correct.

The CSS is present.

The selector is correct.

The z-index looks higher.

And yet the UI is broken.

That’s when CSS specificity stops being a beginner topic and becomes a production debugging problem.

The Production Incident That Started This

Recently, I was working on a microfrontend application.

Everything worked fine initially.

I opened a page, launched a modal and the UI looked correct.

Then I navigated to another microfrontend.

Its CSS got loaded.

After returning to the original microfrontend, suddenly:

❌ Modal appeared behind page content
❌ Overlay behaved incorrectly
❌ z-index looked correct but wasn't working

DevTools showed my CSS rule still existed.

Yet another CSS rule was winning.

The culprit?

CSS Specificity.

🧠 What is CSS Specificity?

CSS specificity is the algorithm browsers use to decide:

Which CSS rule wins when multiple rules target the same element.

Browsers don't simply apply:

"The last CSS rule."

That's one of the biggest misconceptions.

Specificity is calculated first.

Only when specificity is equal does source order become important.

⚔️ Example

.modal {
  z-index: 9999;
}

.some-library .modal {
  z-index: 100;
}

HTML:

<div class="some-library">
  <div class="modal"></div>
</div>

Many developers expect:

.modal

to win because the value is larger.

But CSS doesn't compare values first.

It compares selectors.

🧮 How Specificity Works

Specificity is usually represented as:

ID - CLASS - TYPE

Specificity Table

Selector	Specificity
`*`	0-0-0
`div`	0-0-1
`.modal`	0-1-0
`[type="text"]`	0-1-0
`:hover`	0-1-0
`#dialog`	1-0-0
Inline Style	Highest

MDN defines specificity as the weight browsers calculate to determine which declaration gets applied when multiple selectors match the same element.

Example Calculation

Selector:

button.primary

Contains:

button     → 0-0-1
.primary   → 0-1-0

Total:

0-1-1

Another selector:

#header button.primary

Contains:

#header   → 1-0-0
button    → 0-0-1
.primary  → 0-1-0

Total:

1-1-1

This selector wins.

❌ Myth #1 — Last CSS Always Wins

Many developers believe:

The CSS rule written last wins.

Not always.

Example:

#header {
  color: red;
}

div {
  color: blue;
}

HTML:

<div id="header">
  Hello
</div>

Result:

Red

Why?

Because:

#header = 1-0-0
div     = 0-0-1

Specificity wins before source order.

❌ Myth #2 — Higher z-index Always Wins

This causes countless production bugs.

Developers often write:

.modal {
  z-index: 99999;
}

And expect it to appear above everything.

Not necessarily.

Because:

z-index works inside stacking contexts.

🧠 What is a Stacking Context?

A stacking context is a separate layering environment.

Example:

.parent {
  position: relative;
  z-index: 1;
}

.child {
  position: absolute;
  z-index: 999999;
}

Even with:

the child cannot escape its parent's stacking context.

This is why modal, tooltip, dropdown, and popover bugs often feel confusing.

The Microfrontend Problem

This is where specificity becomes extremely important.

Imagine:

Microfrontend A

.modal {
  z-index: 9999;
}

Microfrontend B

.layout .modal {
  z-index: 100;
}

Specificity:

.modal
0-1-0

.layout .modal
0-2-0

Microfrontend B wins.

Even if your CSS is still loaded.

Why My Fix Worked

Originally:

.modal {
  z-index: 9999;
}

But another selector had higher specificity.

So I wrapped the modal:

<div class="dialog-wrapper">
  <Modal />
</div>

Then:

.dialog-wrapper .modal {
  z-index: 9999;
}

Before:

.modal
0-1-0

After:

.dialog-wrapper .modal
0-2-0

Now my selector became more specific and started winning.

The CSS value never changed.

Only specificity changed.

And the issue disappeared.

🚨 Why This Happens More in Microfrontends

Microfrontends often share:

Same DOM
Same global CSS
Same class names
Same browser environment

Problems include:

CSS leakage
Style collisions
Unexpected overrides
Load-order changes after navigation

This makes specificity bugs significantly more common.

Modern CSS Specificity Features Developers Often Miss

1️⃣ `:is()`

Example:

:is(.btn, .link)

The :is() pseudo-class itself doesn't add specificity.

Instead, it takes the specificity of the most specific selector inside it.

Example:

:is(.btn, #header)

Specificity:

1-0-0

Because:

#header

is most specific.

2️⃣ `:not()`

Many developers think:

:not(.hidden)

adds nothing.

Not true.

:not() itself doesn't contribute specificity.

But selectors inside it do.

Example:

:not(.hidden)

Specificity:

0-1-0

3️⃣ `:where()`

One of the most underrated CSS features.

Example:

:where(.btn)

Specificity:

0-0-0

Always.

:where() intentionally has zero specificity.

This makes it extremely useful for:

Design systems
Component libraries
Shared UI frameworks

Because consumers can easily override styles.

How to Debug CSS Specificity Issues

When CSS isn't applying:

Check these in order:

1. Is the rule present?

Open DevTools.

Verify the CSS exists.

2. Is it crossed out?

Crossed-out CSS usually means:

Another rule won.

3. Which selector is winning?

DevTools shows the winning selector.

Inspect it carefully.

4. Compare specificity

Many bugs become obvious here.

5. Check CSS load order

When specificity is equal:

Last rule wins.

6. Check stacking contexts

Especially for:

Modals
Dropdowns
Tooltips
Popovers

7. Check portals

React portals often render outside expected DOM hierarchy.

This changes how CSS behaves.

🎯 Best Practices

✅ Prefer class selectors over IDs

✅ Avoid deeply nested selectors

✅ Use low-specificity CSS in shared libraries

✅ Use :where() for easily overridable styles

✅ Be careful with global CSS in microfrontends

✅ Avoid excessive !important

Final Thoughts

Most developers think CSS specificity is a beginner topic.

In reality:

It's one of the most common reasons production UIs break unexpectedly.

Especially in:

Large applications
Design systems
Microfrontends
Shared component libraries

The tricky part is that the CSS often looks correct.

The rule exists.

The value is correct.

And yet another selector silently wins.

Understanding specificity deeply transforms CSS debugging from:

Trial and Error

into:

Predictable Engineering

Key Takeaways

CSS does not simply apply the last rule
Specificity determines which selector wins
Higher z-index does not always mean higher visibility
Microfrontends make specificity issues more common
:is(), :not(), and :where() have special specificity behavior
!important should be a last resort
DevTools can quickly reveal specificity conflicts when used correctly

Understanding CSS specificity is one of those skills that feels minor — until it saves you hours of debugging a production UI issue.

API Pagination - Offset vs Cursor Pagination Explained

Fazal Mansuri — Sat, 16 May 2026 10:42:41 +0000

Most APIs don’t return all records at once.

Imagine:

Millions of users
Thousands of orders
Endless social media posts

Returning everything in a single response would:

Consume huge memory
Slow down queries
Increase network payload
Crash clients

That’s why APIs use:

Pagination

But here’s where many developers make mistakes:

Not all pagination strategies are equal.

The two most common approaches are:

Offset Pagination
Cursor Pagination

And choosing the wrong one can create:

Slow APIs
Duplicate records
Missing data
Poor user experience

Let’s understand everything properly.

🧠 What is Pagination?

Pagination means:

Splitting large datasets into smaller chunks (pages).

Instead of:

GET /posts

You request:

GET /posts?page=1&limit=10

This improves:

Performance
Scalability
User experience

📦 Offset Pagination

Offset pagination is the most common approach.

Example:

GET /posts?offset=20&limit=10

Meaning:

Skip first 20 rows
Return next 10 rows

⚙️ SQL Behind It

SELECT * FROM posts
ORDER BY id
LIMIT 10 OFFSET 20;

Simple Go Example - Offset Pagination

package main

import (
    "encoding/json"
    "log"
    "net/http"
    "strconv"
)

type Post struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

var posts []Post

func init() {
    for i := 1; i <= 100; i++ {
        posts = append(posts, Post{
            ID:    i,
            Title: "Post " + strconv.Itoa(i),
        })
    }
}

func getPosts(w http.ResponseWriter, r *http.Request) {
    query := r.URL.Query()

    offset, _ := strconv.Atoi(query.Get("offset"))
    limit, _ := strconv.Atoi(query.Get("limit"))

    if limit == 0 {
        limit = 10
    }

    end := offset + limit

    if offset > len(posts) {
        offset = len(posts)
    }

    if end > len(posts) {
        end = len(posts)
    }

    result := posts[offset:end]

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(result)
}

func main() {
    http.HandleFunc("/posts", getPosts)

    log.Println("Server running on http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run It

go run offset-pagination.go

📡 API Call

curl "http://localhost:8080/posts?offset=20&limit=5"

📦 Response

[
  {
    "id": 21,
    "title": "Post 21"
  },
  {
    "id": 22,
    "title": "Post 22"
  },
  {
    "id": 23,
    "title": "Post 23"
  },
  {
    "id": 24,
    "title": "Post 24"
  },
  {
    "id": 25,
    "title": "Post 25"
  }
]

✅ Advantages of Offset Pagination

Simple to implement
Easy to understand
Supports random page access

Example:

?page=50

❌ Problems with Offset Pagination

This is where things become interesting.

⚠️ Problem 1 — Slow Queries at Scale

Imagine:

LIMIT 10 OFFSET 1000000

Database still scans and skips 1 million rows.

💥 Very expensive.

⚠️ Problem 2 — Duplicate / Missing Records

Suppose user loads:

Page 1

Meanwhile:

New rows inserted
Old rows deleted

Now user loads:

Page 2

Result:

Duplicate rows
Missing rows

📉 Visual Problem

Before:

1 2 3 4 5 6 7 8 9 10

User fetches:
OFFSET 0 LIMIT 5

Gets:
1 2 3 4 5

Now new record inserted at top:

0 1 2 3 4 5 6 7 8 9 10

User fetches:
OFFSET 5 LIMIT 5

Gets:
5 6 7 8 9

⚠️ Duplicate "5"

🚀 Cursor Pagination

Cursor pagination solves these problems.

Instead of:

Skipping rows

We say:

Give records AFTER this specific item.

Example:

GET /posts?cursor=20&limit=10

Meaning:

Give next 10 posts after ID 20

⚙️ SQL Behind It

SELECT * FROM posts
WHERE id > 20
ORDER BY id
LIMIT 10;

Database uses index efficiently.

Simple Go Example — Cursor Pagination

package main

import (
    "encoding/json"
    "log"
    "net/http"
    "strconv"
)

type Post struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

var posts []Post

func init() {
    for i := 1; i <= 100; i++ {
        posts = append(posts, Post{
            ID:    i,
            Title: "Post " + strconv.Itoa(i),
        })
    }
}

func getPosts(w http.ResponseWriter, r *http.Request) {
    query := r.URL.Query()

    cursor, _ := strconv.Atoi(query.Get("cursor"))
    limit, _ := strconv.Atoi(query.Get("limit"))

    if limit == 0 {
        limit = 10
    }

    var result []Post

    for _, post := range posts {
        if post.ID > cursor {
            result = append(result, post)

            if len(result) == limit {
                break
            }
        }
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(result)
}

func main() {
    http.HandleFunc("/posts", getPosts)

    log.Println("Server running on http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run It

go run cursor-pagination.go

📡 API Call

curl "http://localhost:8080/posts?cursor=10&limit=5"

📦 Response

[
  {
    "id": 11,
    "title": "Post 11"
  },
  {
    "id": 12,
    "title": "Post 12"
  },
  {
    "id": 13,
    "title": "Post 13"
  },
  {
    "id": 14,
    "title": "Post 14"
  },
  {
    "id": 15,
    "title": "Post 15"
  }
]

✅ Advantages of Cursor Pagination

Fast for large datasets
Uses indexes efficiently
No duplicate/missing rows issue
Better for real-time systems

⚠️ Trade-Offs of Cursor Pagination

Not perfect either.

❌ No Random Page Access

You cannot easily jump to:

Page 50

Need sequential navigation.

❌ More Complex Implementation

Need:

Stable sorting
Unique cursor
Cursor encoding sometimes

🧠 What Companies Usually Do

🟢 Offset Pagination

Used for:

Admin panels
Internal dashboards
Small datasets

🟣 Cursor Pagination

Used for:

Social media feeds
Infinite scroll
Messaging apps
Large-scale APIs

🔥 Real-World Example

Instagram / Twitter Feed

Do you think they use:

OFFSET 5000000

❌ No chance.

They use cursor-based pagination.

⚡ Performance Difference

Offset Pagination

OFFSET 1000000

DB scans huge rows ❌

Cursor Pagination

WHERE id > 1000000

Direct index lookup ✅

🔐 Important Cursor Pagination Rule

Cursor field must be:

Indexed
Unique
Stable

Usually:

ID
Created timestamp

⚠️ Common Developer Mistakes

❌ Using OFFSET for infinite scroll

Bad at scale.

❌ Cursor based on non-unique column

Can create duplicates.

❌ Forgetting stable ordering

Pagination becomes inconsistent.

🧠 Key Mental Model

Offset Pagination

“Skip N rows”

Cursor Pagination

“Continue after this row”

📊 Quick Comparison

Feature	Offset Pagination	Cursor Pagination
Easy implementation	✅	❌
Random page access	✅	❌
Large dataset performance	❌	✅
Infinite scroll	❌	✅
Duplicate/missing record safety	❌	✅

🏁 Final Thoughts

Pagination seems simple.

But poor pagination strategy can:

Slow down APIs
Break user experience
Create inconsistent data

🎯 Key Takeaways

Offset pagination is simple but doesn’t scale well
Cursor pagination is efficient and production-friendly
Infinite scroll systems should prefer cursor pagination
Always use indexed & stable cursor fields

Good API design is not just about returning data.

It’s about returning data efficiently — even at massive scale.

GraphQL vs REST - Which One Should You Really Use?

Fazal Mansuri — Sun, 26 Apr 2026 07:04:52 +0000

For years, REST APIs have been the standard.

Then GraphQL came in with promises like:

“Fetch exactly what you need”
“Reduce API calls”
“More flexible APIs”

But here’s the reality:

GraphQL is not a replacement for REST.
It’s a different trade-off.

Let’s break it down — with real code you can run.

🧠 What is REST?

REST is a resource-based API design.

You expose endpoints like:

GET /users/1
GET /users/1/orders

Each endpoint returns fixed structure data.

⚙️ REST API — Fully Working Go Example

👉 Save as rest.go

package main

import (
    "encoding/json"
    "log"
    "net/http"
)

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

func getUserHandler(w http.ResponseWriter, r *http.Request) {
    user := User{
        ID:    1,
        Name:  "John",
        Email: "john@example.com",
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(user)
}

func main() {
    http.HandleFunc("/users/1", getUserHandler)

    log.Println("REST server running on http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run it

go run rest.go

📡 Call API

curl http://localhost:8080/users/1

📦 Response

{
  "id": 1,
  "name": "John",
  "email": "john@example.com"
}

🧠 What is GraphQL?

GraphQL is a query-based API system.

Instead of multiple endpoints:

You use a single endpoint
Client decides what data it needs

⚙️ GraphQL API — Fully Working Go Example

👉 Save as graphql.go

Step 1: Install dependency

go mod init graphql-example
go get github.com/graphql-go/graphql

Step 2: Full working code

package main

import (
    "encoding/json"
    "log"
    "net/http"

    "github.com/graphql-go/graphql"
)

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

var userData = User{
    ID:    1,
    Name:  "John",
    Email: "john@example.com",
}

func main() {

    // Define User type
    userType := graphql.NewObject(graphql.ObjectConfig{
        Name: "User",
        Fields: graphql.Fields{
            "id": &graphql.Field{
                Type: graphql.Int,
            },
            "name": &graphql.Field{
                Type: graphql.String,
            },
            "email": &graphql.Field{
                Type: graphql.String,
            },
        },
    })

    // Root query
    rootQuery := graphql.NewObject(graphql.ObjectConfig{
        Name: "Query",
        Fields: graphql.Fields{
            "user": &graphql.Field{
                Type: userType,
                Resolve: func(p graphql.ResolveParams) (interface{}, error) {
                    return userData, nil
                },
            },
        },
    })

    schema, err := graphql.NewSchema(graphql.SchemaConfig{
        Query: rootQuery,
    })
    if err != nil {
        log.Fatal(err)
    }

    // GraphQL handler
    http.HandleFunc("/graphql", func(w http.ResponseWriter, r *http.Request) {
        var params struct {
            Query string `json:"query"`
        }

        err := json.NewDecoder(r.Body).Decode(&params)
        if err != nil {
            http.Error(w, "invalid request body", http.StatusBadRequest)
            return
        }

        result := graphql.Do(graphql.Params{
            Schema:        schema,
            RequestString: params.Query,
        })

        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(result)
    })

    log.Println("GraphQL server running on http://localhost:8080/graphql")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

▶️ Run it

go run graphql.go

📡 Call API

curl -X POST http://localhost:8080/graphql \
-H "Content-Type: application/json" \
-d '{"query": "{ user { name email } }"}'

📦 Response

{
  "data": {
    "user": {
      "name": "John",
      "email": "john@example.com"
    }
  }
}

REST vs GraphQL — Visual Understanding

REST Flow

Client
  |
  |---- GET /users/1 ----------> Server
  |---- GET /users/1/orders ---> Server
  |---- GET /orders/101/items -> Server

Multiple requests ❌

GraphQL Flow

Client
  |
  |---- POST /graphql ---------> Server
        query {
          user {
            orders {
              items
            }
          }
        }

Single request ✅

⚠️ The Real Problem GraphQL Solves

REST Problem → Over-fetching

GET /users/1

Returns:

name, email, address, phone...

Even if you need only name.

REST Problem → Under-fetching

You need multiple calls to build UI.

GraphQL Solution

query {
  user {
    name
  }
}

👉 Exact data only.

⚖️ REST vs GraphQL — Honest Comparison

🧩 REST

✅ Simple
✅ Easy caching
✅ Easy debugging
❌ Multiple calls
❌ Over-fetching

🧩 GraphQL

✅ Flexible
✅ Single request
❌ Complex
❌ Hard caching

Note: REST uses native HTTP caching (like CDNs and browser headers), while GraphQL requires complex, custom caching strategies because queries are typically sent via POST.

❌ Query abuse risk

⚠️ Common Mistakes

❌ “GraphQL is always better”

No.

❌ Using GraphQL for simple CRUD

Overkill.

❌ Ignoring query complexity

Bad query:

users → posts → comments → replies → ...

💥 Performance issue

🧠 When to Use What

✅ Use REST when:

Simple APIs
CRUD operations
Strong caching needed
Easy debugging required

✅ Use GraphQL when:

Complex frontend
Aggregated data
Multiple services
Frequent UI changes

🔗 Real-World Architecture

Many companies use the GraphQL Gateway (or BFF) pattern:

Frontend → GraphQL Gateway → REST microservices

👉 GraphQL acts as an aggregation layer, allowing you to combine multiple REST responses into one, without refactoring the legacy backend.

🏁 Final Thoughts

GraphQL vs REST is not a battle.

It’s a design decision.

🎯 Key Takeaways:

REST = simple and predictable
GraphQL = flexible but complex
Both solve real problems
Choose based on use-case

🚀 Final Tip

If your API:

👉 Is simple → use REST
👉 Needs flexibility → use GraphQL

⚠️ 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! 👇

DEV Community: Fazal Mansuri

📦 AI Context Engineering (Part 2): Tokens, Context Windows & Memory - Why More Context Isn't Always Better

🤔 "Didn't I Already Tell You That?"

🧠 Before We Talk About Context Windows…

🔤 What Exactly Is a Token?

Tokens ≠ Words

📦 Different Types of Content Produce Different Numbers of Tokens

Example 1 — Simple English

Example 2 — JSON

Example 3 — Source Code

Example 4 — URLs

Example 5 — Emojis

💡 The Important Lesson

🎯 Why Should Developers Care About Tokens?

💰 Everything Consumes Tokens

🔄 Every New Request Starts Again

🪟 What Is a Context Window?

📖 What's Actually Inside the Context Window?

🤔 Does a Bigger Context Window Always Mean Better AI?

🎯 More Context ≠ Better Context

🔍 The "Lost in the Middle" Problem

🧠 Context Is NOT Memory

Context

Memory

🏗️ A Simple Mental Model

💰 Why Tokens Matter for Cost and Performance

Efficient Request

Inefficient Request

⚙️ How Production AI Systems Manage Context

✅ Retrieve Only What's Relevant

✅ Summarize Long Conversations

✅ Keep System Prompts Focused

✅ Separate Long-Term Memory from Current Context

✅ Measure Token Usage

🚫 Common Context Engineering Mistakes

❌ Dumping entire documents into every request

❌ Sending the full conversation forever

❌ Treating memory as conversation history

❌ Ignoring token usage

❌ Assuming bigger context windows solve everything

🎯 Best Practices

🏁 Final Thoughts

📌 Key Takeaways

🚀 Coming Up in Part 3

🧠 AI Context Engineering — Why Great AI Systems Need More Than Great Prompts (Part 1)

What Is Context Engineering?

A Simple Analogy

Developer A

Developer B

Prompt vs Context

Why Prompt Engineering Alone Isn't Enough

What Actually Forms the Context?

A Real-World Example

Another Example: ChatGPT

The Mental Shift

Common Misconceptions

❌ "A bigger prompt always gives better answers."

❌ "Prompt Engineering is no longer useful."

❌ "Only AI engineers need to know this."

Why This Matters More Than Ever

What's Coming in Part 2?

Key Takeaways

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

The Production Incident That Started This

🧠 What is CSS Specificity?

⚔️ Example

🧮 How Specificity Works

Specificity Table

Example Calculation

❌ Myth #1 — Last CSS Always Wins

❌ Myth #2 — Higher z-index Always Wins

🧠 What is a Stacking Context?

The Microfrontend Problem

Microfrontend A

Microfrontend B

Why My Fix Worked

🚨 Why This Happens More in Microfrontends

Modern CSS Specificity Features Developers Often Miss

1️⃣ :is()

2️⃣ :not()

1️⃣ `:is()`

2️⃣ `:not()`

3️⃣ `:where()`