DEV Community: Sanu Khan

52 Possibilities. 5 Cards. No Guessing. Here’s the Algorithm.

Sanu Khan — Mon, 05 Oct 2026 05:45:00 +0000

I recently came across a card trick that initially looked like ordinary magic.

Five cards are selected from a standard 52-card deck.

One card is hidden.

The other four are shown to another person in a carefully chosen order.

And somehow, from those four cards alone, they can determine exactly which fifth card is missing.

No marked cards.

No probability.

No machine learning.

No brute force.

Just mathematics.

What interested me wasn't really the trick itself.

It was how closely the solution resembles something we do constantly in software engineering:

Reduce the problem space before trying to compute the answer.

And the first step comes from one of the simplest ideas in discrete mathematics: the Pigeonhole Principle.

The Pigeonhole Principle

The classic definition is simple:

If you place more pigeons than pigeonholes, at least one pigeonhole must contain more than one pigeon.

If you put 5 pigeons into 4 holes, some hole must contain at least 2 pigeons.

Formally, distributing n objects among m containers where:

n > m

guarantees that at least one container contains multiple objects.

More generally, at least one bucket contains:

ceil(n / m)

objects.

That sounds almost too obvious to be useful.

But this tiny observation can give us surprisingly powerful guarantees.

Five Cards, Four Suits

Consider a standard deck.

There are four suits:

♠ Spades
♥ Hearts
♦ Diamonds
♣ Clubs

Now select five cards.

We have:

Objects      = 5 cards
Buckets      = 4 suits

Because:

5 > 4

at least two cards must have the same suit.

Not probably.

Not usually.

Always.

For example:

3♠
9♠
K♥
5♦
7♣

There are two spades.

That duplicated suit becomes our first piece of information.

Suppose we hide:

9♠

and reveal:

3♠

The person decoding the trick already knows something important:

Hidden card suit = ♠

We have eliminated three quarters of the deck without explicitly communicating the suit.

But we still need the rank.

That's where the trick becomes much more interesting.

Turning 13 Ranks Into Only 6 Possibilities

A suit contains 13 ranks:

A 2 3 4 5 6 7 8 9 10 J Q K

Instead of thinking about this as a line, think of it as a circular data structure:

A → 2 → 3 → ... → Q → K
↑                   ↓
└───────────────────┘

Now take any two cards of the same suit.

There are two possible directions between them around this circle.

Those distances together equal 13.

Therefore, at least one direction must have a distance of at most 6.

So the person arranging the cards chooses which card to reveal and which to hide such that:

distance = 1..6

Suddenly our problem has changed.

Originally we needed to identify one card among 52.

Now we already know the suit and only need to communicate one of:

That is a dramatic reduction in the search space.

But How Do We Transmit 1–6?

Remember that five cards were originally selected.

Two are being used for our same-suit pair:

1 visible key card
1 hidden card

That leaves three cards.

Three distinct objects can be arranged in:

3! = 3 × 2 × 1 = 6

different ways.

Exactly six.

So the ordering of those three cards can represent the numbers 1 through 6.

Conceptually:

ABC → 1
ACB → 2
BAC → 3
BCA → 4
CAB → 5
CBA → 6

The precise mapping doesn't matter as long as the encoder and decoder agree on it.

Suppose the first visible card is:

3♠

and the remaining cards appear in the permutation representing:

+6

The decoder performs:

3 + 6 = 9

and therefore knows that the hidden card is:

9♠

What looked like magic was actually a communication protocol.

This Is an Encoding Algorithm

Think about the roles involved.

The first person is an:

Encoder

The second person is a:

Decoder

The order of the cards is the:

Message

And their shared understanding of the ordering convention is the:

Protocol

That's remarkably close to what we build in software every day.

The cards aren't merely being displayed.

Their arrangement carries information.

In other words:

Physical state → encoded information

That idea appears everywhere in computing.

A bit uses two states:

0
1

Two bits provide:

Four states.

Three bits provide eight states.

Likewise, three cards provide:

3! = 6

possible ordering states.

The trick is essentially exploiting the information capacity of permutations.

Why This Matters for Software Engineers

When systems become computationally expensive, our first instinct is often:

"How do we calculate this faster?"

But a better question is frequently:

"How much of this do we actually need to calculate?"

That distinction matters enormously.

Consider a hypothetical search problem with:

1,000,000,000 candidates

Throwing more CPU at the problem might make each comparison faster.

But suppose mathematical or domain constraints let us eliminate 99.999% of the candidates before searching.

Now we're dealing with perhaps:

10,000 candidates

The biggest optimization wasn't faster hardware.

It was not performing unnecessary computation in the first place.

The card trick does exactly this.

It transforms:

Find 1 card among 52

into approximately:

Determine suit from the key card
+
decode one value from 1..6

The representation of the problem changes.

And once the representation changes, the computation becomes trivial.

Example 1: Hash Tables

Consider inserting users into buckets using a hash:

function bucketFor(userId, bucketCount) {
  return hash(userId) % bucketCount;
}

Suppose:

users   = 1,000,000
buckets = 10,000

The generalized pigeonhole principle tells us immediately that some buckets necessarily contain multiple users.

In fact, at least one bucket contains at least:

ceil(1,000,000 / 10,000)

= 100

users.

This is why collisions aren't an unexpected failure of hashing.

They're mathematically inevitable whenever the input space exceeds the output space.

The engineering question therefore isn't:

Can collisions happen?

It's:

How efficiently do we handle inevitable collisions?

That leads directly to concepts such as chaining, open addressing, load factors and resizing.

Example 2: Database Partitioning and Sharding

Imagine distributing:

100 million customers

across:

100 database shards

Even under perfect distribution, we're looking at roughly:

1,000,000 customers / shard

But real-world keys rarely distribute perfectly.

Understanding the number of objects relative to the number of buckets helps us reason about:

hot partitions
skew
capacity planning
partition-key design
rebalancing

Consider:

const shard = customerId % SHARD_COUNT;

This looks innocent.

But the quality of the partition key determines whether your load looks like:

Shard 1 → 1M
Shard 2 → 1M
Shard 3 → 1M
...

or:

Shard 1 → 12M
Shard 2 → 300K
Shard 3 → 800K
...

The mathematics gives us the lower-level guarantee.

Architecture determines whether the real-world distribution is useful.

Example 3: Scheduling and Resource Allocation

Suppose a system receives:

101 jobs

and has:

10 workers

At least one worker must receive:

ceil(101 / 10) = 11

jobs.

Again, that's not a performance prediction.

It's a mathematical guarantee about distribution.

This kind of reasoning becomes useful when designing:

worker pools
queue consumers
thread pools
Kubernetes workloads
batch processors
rate-limited APIs

Before benchmarking anything, mathematics can sometimes tell us what load conditions must exist.

Example 4: Duplicate Detection

Here's another interesting one.

Imagine generating identifiers containing only the numbers:

0000 - 9999

There are exactly:

10,000

possible IDs.

If your system creates:

10,001

active records while requiring every ID to be unique, you don't need monitoring to determine whether a collision can occur.

A collision is guaranteed.

No amount of better random-number generation fixes this.

The namespace itself is insufficient.

This distinction is important:

Randomness ≠ uniqueness

If the available state space is smaller than the number of objects that require unique states, collision avoidance becomes mathematically impossible.

Example 5: Distributed Systems

Suppose 50,000 requests must be assigned to 100 processing nodes.

The pigeonhole principle immediately tells us:

some node handles at least 500 requests

That's merely the lower bound.

Real systems introduce skew through:

geography
tenant size
cache affinity
sticky sessions
partition keys
time-of-day traffic
retry storms

So the practical maximum may be much larger.

But mathematical bounds are useful because they give architects something important before simulation even begins:

a guaranteed constraint.

High-Order Computation Isn't Always About More Compute

This is the larger lesson I took from the trick.

When we're dealing with large computational spaces—optimization problems, search algorithms, distributed workloads or AI systems—we often focus on increasing computational power.

More CPUs.

More GPUs.

More memory.

More workers.

More parallelism.

But algorithm design frequently wins by changing the problem before computation begins.

Suppose an algorithm searches n elements:

O(n)

Reducing execution time by 50% is useful.

But suppose domain constraints reduce the candidate set from:

to:

log(n)

or allow us to restructure the algorithm entirely.

That's a fundamentally different optimization.

This is why computer science spends so much time on:

data structures
constraints
invariants
combinatorics
graph theory
probability
information theory
complexity analysis

We aren't merely learning ways to make computers calculate.

We're learning ways to make computers calculate less.

Think About Search Algorithms

A linear search through one billion values potentially requires:

1,000,000,000 comparisons

If the data is ordered, binary search reduces that to approximately:

log₂(1,000,000,000) ≈ 30

That's astonishing.

We didn't build a CPU that is 33 million times faster.

We changed the structure of the problem.

Linear search:

1,000,000,000 possibilities
        ↓
 potentially 1,000,000,000 operations


Binary search:

1,000,000,000 possibilities
        ↓
 ~30 decisions

The card trick follows the same philosophy.

Don't inspect every possible card.

Encode constraints into the representation until the remaining answer becomes trivial.

The Information-Theory Perspective

There's another layer to this.

When three cards are ordered, there are:

3! = 6

possible messages.

The information capacity is therefore:

log₂(6) ≈ 2.585 bits

That's enough information to distinguish among six possibilities.

So the magician and assistant have effectively constructed a tiny communication channel without saying anything.

This general principle appears throughout computing.

For n distinct objects, their ordering can represent:

n!

states.

The information encoded by the permutation is approximately:

log₂(n!)

bits.

As n grows, this becomes surprisingly large.

For example:

5!  = 120 states
10! = 3,628,800 states
20! ≈ 2.43 × 10¹⁸ states

Permutation isn't merely ordering.

Ordering itself can be data.

This Pattern Appears Everywhere

Once you start looking for this idea, you see variations of it throughout software engineering.

Hashing
    ↓
Map a huge key space into manageable buckets.

Database indexes
    ↓
Avoid scanning the entire dataset.

Binary search
    ↓
Discard half the remaining state space per decision.

Bloom filters
    ↓
Use compact probabilistic state to avoid expensive lookups.

Caching
    ↓
Avoid recomputing known results.

Database partitioning
    ↓
Reduce the portion of data involved in an operation.

Branch-and-bound
    ↓
Eliminate entire regions of a search tree.

Dynamic programming
    ↓
Avoid solving identical subproblems repeatedly.

Constraint propagation
    ↓
Eliminate impossible states before exploring them.

Different techniques.

Same broader philosophy:

Use information and constraints to eliminate unnecessary computation.

A Useful Engineering Question

When facing an expensive problem, we often ask:

How can we process this faster?

I've started to think the more valuable sequence is:

What do we know?

↓

What can those constraints eliminate?

↓

How much information do we actually need?

↓

Can the representation encode some of that information?

↓

What remains to be computed?

↓

Only then: how do we compute it efficiently?

That ordering matters.

Because sometimes the difference between an expensive problem and a trivial one isn't hardware.

It's discovering the right invariant.

From Five Cards to System Design

That's what I liked about this particular card trick.

Five cards.

Four suits.

One unavoidable duplicate.

Six possible distances.

Six permutations.

And suddenly a seemingly impossible prediction becomes deterministic.

Pigeonhole Principle
        ↓
Find guaranteed structure

Cyclic arithmetic
        ↓
Reduce rank distance to 1..6

Permutations
        ↓
Encode one of six possibilities

Decoder
        ↓
Reconstruct the hidden information

There is no magic left once you understand the protocol.

But from an engineering perspective, I think what replaces the magic is considerably more interesting.

Final Thought

Some of the most powerful optimizations don't make computation faster.

They make computation unnecessary.

The pigeonhole principle is elementary mathematics, but combined with constraints, permutations and encoding, it can transform the structure of a problem.

That's equally true whether you're predicting a playing card or designing a distributed system.

Before scaling infrastructure, increasing parallelism or throwing more compute at a difficult problem, ask:

Is there a mathematical property of the problem that lets me reduce the state space first?

Sometimes the smartest computation is the one you successfully avoid.

I Built an ERP in 25 Hours With AI — Vibe Coding Is Getting Serious

Sanu Khan — Mon, 28 Sep 2026 08:28:25 +0000

TL;DR: In roughly 25 hours, I went from requirements and architecture to a working full-stack ERP with a modern Angular UI, Laravel APIs, MySQL, operational workflows, dashboards, accounting features, reporting, and an integrated AI assistant.

Not a landing page.

Not a CRUD demo.

An actual ERP.

And the interesting part isn't that AI replaced the developer.

It didn't.

The interesting part is how much more a developer can now accomplish when AI becomes part of the engineering workflow.

From requirements to a working system

I started with what would traditionally become weeks of architecture discussions, boilerplate, migrations, APIs, UI screens, validations, and integration work.

The stack itself was intentionally conventional:

Angular
    ↓
REST API
    ↓
Laravel
    ↓
MySQL

The goal wasn't to experiment with an exotic AI-generated architecture.

It was to see how quickly a conventional, maintainable application could be built when AI handled much of the repetitive implementation work while I remained responsible for architecture, constraints, review, and direction.

Within about 25 hours, the project had grown into a surprisingly substantial application.

It included areas such as:

authentication and authorization
multi-branch application context
users and roles
customer management
property management
agreement workflows
payment schedules
inward and outward transactions
receipts
petty-cash/daybook workflows
operational dashboards
accounts dashboards
maintenance workflows
inventory
purchase workflows
reports
audit-aware operations
AI-assisted ERP interaction

This wasn't generated from one magical prompt.

It was an iterative engineering process.

Codex became an implementation multiplier

A large portion of the development loop became:

Requirement
   ↓
Architecture / constraints
   ↓
Codex task
   ↓
Implementation
   ↓
Review
   ↓
Test
   ↓
Refine

That distinction matters.

AI is extremely fast at producing code.

But producing code and engineering a system are still different things.

I still had to decide how modules should interact, where transaction boundaries belonged, what needed server-side validation, how authorization should work, how financial operations should behave, what should be immutable, and where the generated implementation needed simplification.

The project's backend, for example, uses explicit transaction boundaries for operations where partial success would be unacceptable.

The development workflow also retained the normal engineering concerns: backend and frontend testing, authorization verification, isolation checks, migration review, API compatibility, and regression testing.

AI accelerated those decisions into working software.

It didn't eliminate the decisions.

Then I attacked the UI

The first functional UI looked exactly like many internal systems do.

It worked.

But it looked like an ERP.

Tables. Forms. Cards. Navigation. Data.

Functional, but traditional.

So I used AI-assisted design iterations with Antigravity to rethink the frontend instead of accepting the usual "enterprise software has to look boring" assumption.

The direction moved toward a modern SaaS-style workspace:

Traditional ERP
     ↓
Functional UI
     ↓
AI-assisted design iteration
     ↓
Modern operational workspace

The resulting interface uses a calm neutral canvas, dark navigation, rounded surfaces, stronger typography, compact controls, high-density tables, modern KPI cards, restrained gradients, and carefully placed accent colors.

The important lesson here was that AI wasn't only accelerating code generation.

It was accelerating design iteration.

Instead of spending hours manually experimenting with spacing, hierarchy, card treatments, dashboard composition, form density, and responsive behavior, I could describe the problem, evaluate an iteration, and immediately push it further.

The loop became:

Screenshot
→ critique
→ design direction
→ implementation
→ screenshot
→ refine

That dramatically shortened the distance between "functional" and "polished."

And then came Zaakiy AI

The part I'm most interested in is the AI layer.

I call the assistant Zaakiy AI.

Instead of treating AI as a chatbot floating beside the application, the idea was to make it understand the ERP through controlled application capabilities.

For example, an ERP assistant should eventually understand questions such as:

"Show me agreements expiring soon."

"Summarize outstanding payments."

"Explain what's happening on this dashboard."

"Summarize this agreement."

"Show me open maintenance issues."

"Which inventory items are running low?"

The architecture deliberately avoids giving the model unrestricted database access.

Instead, AI operates through narrow application capabilities such as dashboard metrics, property searches, agreement retrieval, outstanding-payment queries, and controlled draft actions.

And that's an important distinction for production AI.

User
 ↓
Zaakiy AI
 ↓
Authorized application tools
 ↓
Application services
 ↓
Database

Not:

AI
 ↓
"Here's the database. Good luck."

AI should remain an assistant layer rather than becoming the system of record.

High-impact operations can still require explicit confirmation, while the backend continues enforcing normal authorization and validation.

That feels much closer to where enterprise AI is heading.

25 hours changed my perspective

I've been writing software long enough to recognize how much work normally hides behind something like this.

Database migrations.

Models.

Relationships.

Validation.

Authorization.

Controllers.

Services.

API resources.

Frontend services.

Types.

Forms.

Tables.

Filters.

Pagination.

Dashboards.

Error states.

Responsive behavior.

Tests.

Then the endless integration work between all of them.

AI compresses a huge amount of that mechanical work.

A feature that might previously consume half a day can sometimes reach its first working version in minutes.

That doesn't mean every generated line is correct.

It means the cost of iteration has collapsed.

And that changes how you build.

Vibe coding doesn't mean "don't understand the code"

This is where I think the conversation around vibe coding sometimes goes wrong.

There are two very different versions of it.

The dangerous version is:

Prompt
→ accept everything
→ ship

The useful version is:

Understand the problem
→ define constraints
→ let AI implement
→ inspect the result
→ test
→ correct
→ simplify
→ repeat

The second version is incredibly powerful.

You can spend less time typing repetitive code and more time thinking about architecture, edge cases, UX, data integrity, security, and what the product should actually do.

The developer moves up a level of abstraction.

AI isn't replacing developers. It's changing developer throughput.

After this experiment, that's the biggest takeaway for me.

The question isn't:

"Can AI build software?"

Clearly, it can build significant portions of software already.

A more interesting question is:

"What happens when an experienced developer can iterate at 5x or 10x their previous speed?"

Because that's what this felt like.

Not replacing engineering.

Amplifying it.

A developer who understands architecture, databases, APIs, security, frontend engineering, UX, and the business problem can now orchestrate multiple AI systems across the development lifecycle.

One AI helps implement.

Another helps critique the interface.

Another helps reason through architecture.

Another helps generate tests.

The developer remains the person connecting all of those outputs into one coherent system.

The bottleneck is moving

For years, a major bottleneck in software development was simply producing the implementation.

Writing all the migrations.

Writing all the endpoints.

Writing all the forms.

Writing all the components.

Writing all the tests.

That bottleneck is shrinking rapidly.

The new bottlenecks are becoming:

Can you describe the system precisely?

Can you design good boundaries?

Can you recognize when generated code is wrong?

Can you protect data integrity and security?

Can you design a coherent user experience?

Can you decide what should—and shouldn't—be automated?

Those are engineering questions.

And arguably, they're the more interesting ones.

25 hours. One developer. A lot of AI.

What I built would traditionally have required considerably more implementation time.

AI didn't magically make software engineering easy.

It made iteration unbelievably fast.

And once you combine that speed with engineering judgment, modern coding agents, AI-assisted UI design, and application-native assistants like Zaakiy AI, the amount of software one developer can produce starts looking very different.

Vibe coding isn't the end of developers.

It might be the beginning of a period where developers can finally spend less time translating decisions into boilerplate—and more time making the decisions that actually matter.

And we're still very early.

Codex CLI 0.157.0 Broke on Windows — Here’s How I Got Back to Work [DO NOT UPDATE CODEX !! ]

Sanu Khan — Fri, 25 Sep 2026 18:59:36 +0000

I updated Codex CLI expecting the usual experience:

codex

Instead, Codex stopped starting normally.

The update had introduced a background daemon, and on my Windows machine it immediately failed with:

Installing daemon from CLI version 0.157.0 into C:\Users\<USER>\.codex\packages\app-server-daemon...
Error: Access is denied. (os error 5)

To work without the background server, rerun the same command with --no-daemon
(including resume or fork and its arguments).

My first reaction was the usual Windows debugging checklist:

Is this a permissions problem?
Is Defender blocking something?
Is a process holding the daemon executable?
Did I somehow launch PowerShell as administrator?

But after checking the Codex repository, it became clear I wasn't the only one.

There is now an open GitHub issue tracking the problem:

openai/codex #48043 — Codex CLI 0.157.0 fails to start on Windows with daemon privilege error

And the interesting part is that there are actually a few variations of the same problem.

What changed in Codex CLI 0.157.0?

The affected release is:

codex-cli 0.157.0

The last version that worked normally for me was:

codex-cli 0.156.1

On 0.157.0, users in the GitHub issue reported daemon-related startup failures including:

Error: Access is denied. (os error 5)

and:

Error: start the Windows daemon from a non-elevated terminal;
shared clients must not inherit administrator privileges

The important detail here is the new/shared background daemon.

Codex is trying to prevent an unsafe privilege boundary where a shared daemon running with administrator privileges could be inherited by non-admin clients.

That security concern makes sense.

The UX problem is what happens next:

if the daemon cannot start, the interactive Codex CLI can fail to start with it.

The temporary workaround: `--no-daemon`

Codex itself tells you about one workaround:

codex --no-daemon

And yes — it worked for me.

So technically I could continue working.

But there was a catch.

The CLI felt noticeably slower compared with my previous setup where the background server was available.

That made --no-daemon useful as an emergency workaround, but not something I wanted to use as my normal development setup.

Another workaround reported in the GitHub discussion is disabling automatic daemon startup in the Codex configuration:

[features]
daemon_auto_start = false

That lets Codex operate without automatically starting the shared daemon.

Again: useful workaround, but it doesn't really solve the regression.

Then I tried the obvious fix: downgrade

At that point I decided to go back to the version that had been working perfectly well:

0.156.1

Several users in the GitHub issue confirmed the same result:

Downgrading to 0.156.1 restores normal operation.

I tested it myself.

And sure enough:

0.156.1 works.

If you installed Codex through npm, the rollback is simple:

npm install -g @openai/codex@0.156.1

But my Codex installation wasn't managed through npm.

I was using the newer standalone Codex CLI installer.

And that's where Windows gave me a second surprise.

The second bug: the standalone installer + Windows PowerShell 5.1

The standalone Windows installer supports pinning a specific Codex release.

So I tried:

$env:CODEX_RELEASE="0.156.1"

irm https://chatgpt.com/codex/install.ps1 | iex

Instead of installing Codex, PowerShell returned:

iex : The property 'OSArchitecture' cannot be found on this object.
Verify that the property exists.

At line:1 char:45
+ irm https://chatgpt.com/codex/install.ps1 | iex
+                                             ~~~

At this point I had gone from:

Codex upgrade problem

to:

Codex downgrade problem

😅

The key detail was my shell version.

I checked:

$PSVersionTable.PSVersion

and discovered I was still running:

Windows PowerShell 5.1

The current Codex Windows installer performs architecture detection using:

[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture

On my PowerShell 5.1 environment, that architecture lookup failed.

So rather than patching the installer locally or switching my Codex installation over to npm, I fixed the shell environment.

Installing PowerShell 7

I installed the current PowerShell release using winget:

winget install --id Microsoft.PowerShell --source winget

That installed:

PowerShell 7.6.6

Then I opened PowerShell 7:

pwsh

and verified it:

$PSVersionTable.PSVersion

Now I had a modern PowerShell environment for the standalone installer.

Downgrading the standalone Codex CLI to 0.156.1

From PowerShell 7, I pinned the Codex release:

$env:CODEX_RELEASE="0.156.1"

Then ran the official installer:

irm https://chatgpt.com/codex/install.ps1 | iex

The installer itself supports the CODEX_RELEASE environment variable.

The relevant part of OpenAI's installer currently looks like this:

param(
    [string]$Release = $env:CODEX_RELEASE
)

if ([string]::IsNullOrWhiteSpace($Release)) {
    $Release = "latest"
}

So:

$env:CODEX_RELEASE="0.156.1"

means:

Install exactly Codex CLI 0.156.1 rather than resolving the latest release.

After installation:

codex --version

should report:

codex-cli 0.156.1

And that's the version I went back to.

The complete Windows workaround

If you're running into this problem today, here's the shortest version.

If you're on Codex CLI 0.157.0

Check:

codex --version

If it reports:

codex-cli 0.157.0

and normal startup fails with a daemon error, you have a few options.

Option 1 — Temporary workaround

codex --no-daemon

This keeps you working without the background daemon.

Option 2 — Disable automatic daemon startup

In your Codex configuration:

[features]
daemon_auto_start = false

This was confirmed by another Windows user in the GitHub discussion.

Option 3 — Roll back to 0.156.1

For npm installations:

npm install -g @openai/codex@0.156.1

For standalone installations, I recommend PowerShell 7.

Install PowerShell:

winget install --id Microsoft.PowerShell --source winget

Start it:

pwsh

Then:

$env:CODEX_RELEASE="0.156.1"
irm https://chatgpt.com/codex/install.ps1 | iex

Verify:

codex --version

Expected:

codex-cli 0.156.1

Then optionally clean up the temporary environment variable:

Remove-Item Env:CODEX_RELEASE

Don't immediately run PowerShell as Administrator

One thing worth highlighting from the GitHub thread:

running the terminal elevated can actually be part of the problem.

One reported error specifically says:

start the Windows daemon from a non-elevated terminal;
shared clients must not inherit administrator privileges

So if your instinct is:

Access denied? I'll just run PowerShell as Administrator.

That may move you directly into the other daemon protection check.

For normal Codex usage, try a standard, non-elevated PowerShell session first.

There is also an interesting edge case documented in the issue where a Windows machine had UAC completely disabled.

On that machine, there effectively wasn't a normal non-elevated token available at all.

In that configuration, telling the user to "open a non-elevated terminal" isn't really actionable.

The user confirmed that:

codex --no-daemon

still worked.

They also suggested that Codex could fall back to its embedded server when daemon startup is rejected rather than terminating the interactive CLI entirely.

That seems like a much smoother failure mode.

Interestingly, this may not be Windows-only

Most of issue #48043 revolves around Windows, and the issue itself currently carries the windows-os label.

However, one user also reported:

Same error on Linux. Reverting to 0.156.1 fixes it.

That's only one report in this particular discussion, so I wouldn't conclude yet that every platform is affected by the same underlying bug.

But it does suggest the regression may involve more than a single Windows permission edge case.

What I'd like to see improved

There are really two separate developer-experience problems here.

1. Daemon startup should fail gracefully

Protecting privilege boundaries is the correct thing to do.

But if the optional/background daemon cannot start, the CLI could potentially fall back automatically rather than making:

codex

unusable.

Something like:

Unable to start shared daemon because this terminal is elevated.

Falling back to embedded server.

Run from a non-elevated terminal to enable the shared daemon.

would be considerably easier to understand.

2. The error needs to identify the failing operation

For the os error 5 case:

Error: Access is denied. (os error 5)

isn't enough information to diagnose the problem properly.

Was Codex trying to:

create a directory?
replace an executable?
delete an old daemon?
rename a file?
open a named pipe/socket?
overwrite a locked binary?
change permissions?

Knowing the exact path and Windows operation would make troubleshooting dramatically easier.

Instead of:

Access is denied

something closer to:

Unable to replace:
C:\Users\<USER>\.codex\packages\app-server-daemon\codex.exe

Windows returned ERROR_ACCESS_DENIED (5).

The file may currently be in use.

would save a lot of debugging time.

What started as a simple upgrade...

The funny part is that this started with something completely routine:

Update Codex CLI.

Then the chain became:

Upgrade to 0.157.0
        ↓
Codex daemon fails
        ↓
Try --no-daemon
        ↓
Works, but slower
        ↓
Decide to downgrade
        ↓
Standalone installer fails under PowerShell 5.1
        ↓
Install PowerShell 7
        ↓
Pin Codex to 0.156.1
        ↓
Back to coding

That's software development in a nutshell.

Sometimes the tool you're using to fix the tool needs fixing first. 😄

TL;DR

If Codex CLI 0.157.0 suddenly stopped working on Windows, you're not necessarily dealing with a broken local project or corrupted Codex configuration.

There is an active upstream issue involving the new daemon behavior.

Temporary workaround:

codex --no-daemon

Stable rollback reported by multiple users:

Codex CLI 0.156.1

For npm:

npm install -g @openai/codex@0.156.1

For the standalone Windows installation:

winget install --id Microsoft.PowerShell --source winget
pwsh

$env:CODEX_RELEASE="0.156.1"
irm https://chatgpt.com/codex/install.ps1 | iex

codex --version

And if you're seeing:

The property 'OSArchitecture' cannot be found

check whether you're still running Windows PowerShell 5.1.

Moving to PowerShell 7 solved that part of the installation path for me.

References

If you landed here because 0.157.0 broke your Codex setup too, add your environment and exact error to the GitHub issue.

Especially include:

OS
Codex CLI version
Installation method
Shell + shell version
Whether terminal is elevated
Exact daemon error
Whether --no-daemon works
Whether 0.156.1 works

The more reproducible environments upstream has, the easier it is to distinguish a permissions problem from a genuine release regression.

Happy coding — and maybe don't hit latest five minutes before an important deployment. 😄

Stop Scaling Out: Your Server Might Just Need More RAM

Sanu Khan — Tue, 08 Sep 2026 05:25:04 +0000

Horizontal scaling sounds architectural. Vertical scaling sounds temporary.

So when an application starts struggling, the instinct is often:

Add instances. Add a load balancer. Scale out.

But sometimes you don't have a distributed-systems problem.

You have a small-server problem.

The Scenario

Imagine your API runs on:

2 vCPU
4 GB RAM
1 application instance

Traffic grows.

CPU starts touching 80%.

Latency increases.

The architecture discussion immediately becomes:

        Load Balancer
             |
      ┌──────┼──────┐
      ▼      ▼      ▼
    App 1  App 2  App 3

But compare that with:

8 vCPU
16 GB RAM
1 application instance

For some workloads, that upgrade might solve the immediate problem with far less operational complexity.

Vertical scaling increases the resources available to an existing machine. Horizontal scaling adds machines and distributes work between them.

Horizontal Scaling Has a Hidden Invoice

Adding another instance isn't simply:

1 server → 2 servers

Your application now has to behave correctly when two independent processes handle requests.

Suddenly you need to think about:

session state
shared caches
distributed locks
background jobs
duplicate processing
connection pools
load balancing
deployment coordination
observability across instances

And eventually:

"We added more application servers."

              ↓

"Why is the database dying?"

Horizontal scaling increases capacity and can improve fault tolerance, but it also introduces networking, coordination and consistency complexity.

But Vertical Scaling Has a Ceiling

This doesn't mean:

Always buy a bigger machine.

Eventually you hit limits.

4 GB  → 8 GB  → 32 GB  → 128 GB
2 CPU → 4 CPU → 16 CPU → 64 CPU

At some point the next machine becomes disproportionately expensive—or simply isn't large enough.

More importantly, one enormous server is still one server.

If it disappears:

BIG SERVER
    ❌
     |
 Entire service unavailable

Vertical scaling can increase capacity without major architectural changes, but hardware limits and single-node failure remain important constraints.

The Better Question

Don't ask:

Horizontal or vertical?

Ask:

What constraint am I actually hitting?

CPU saturated?
      ↓
Can scaling up solve it economically?
      ↓
YES ──────────────► Scale Up
      │
      NO
      ↓
Can workload be distributed safely?
      ↓
YES ──────────────► Scale Out

And don't confuse capacity with availability.

A bigger machine may solve capacity.

Multiple machines may improve redundancy.

Those are related—but different—engineering problems.

The Architecture I Prefer

For many systems:

Start simple
     ↓
Measure
     ↓
Scale vertically
     ↓
Measure again
     ↓
Remove state from compute
     ↓
Scale horizontally when justified

Not every application needs distributed architecture on day one.

And horizontal scaling isn't automatically more mature engineering.

Sometimes the better architectural decision is knowing when not to distribute the system yet.

Because scalability isn't about having more servers.

It's about knowing where your next bottleneck will appear.

What do you usually reach for first when capacity becomes a problem: a bigger machine or another machine?

Round Robin Is Lying to You: Equal Traffic Equal Load

Sanu Khan — Mon, 07 Sep 2026 06:56:02 +0000

> Your load balancer can distribute traffic perfectly and still overload a server. Here's the part of Round Robin we often overlook.

Three servers. Six requests.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A
Request 5 → Server B
Request 6 → Server C

Perfect.

Every server got exactly two requests.

So the load is balanced... right?

Not necessarily.

This is where a simple load-balancing diagram can hide a surprisingly important production problem:

Equal traffic does not mean equal work.

The Problem Isn't the Algorithm

Round Robin is beautifully simple.

You have three servers:

A → B → C → A → B → C

Each new request goes to the next server.

For many systems, that's perfectly reasonable.

The interesting part is what happens when the requests aren't equal.

Imagine this traffic:

GET  /health
POST /generate-report
GET  /profile
POST /export-large-file
GET  /products
POST /process-video

Round Robin might still produce:

Server A → 2 requests
Server B → 2 requests
Server C → 2 requests

On paper:

A = B = C

In production:

Server A  ███░░░░░░░  25%
Server B  █████░░░░░  48%
Server C  █████████░  91%

Same request count.

Very different workload.

One Request Is Not One Unit of Work

A health-check request might finish in a few milliseconds.

Generating a large report could involve:

multiple database queries
significant memory
CPU-heavy processing
external API calls
several seconds of execution

To a basic Round Robin strategy, both are still:

1 request

And that's the trap.

We often think we're distributing load.

What we're actually distributing is requests.

Those are not always the same thing.

Servers Aren't Always Equal Either

There's another assumption hiding here.

Imagine:

Server A → 8 CPU / 16 GB
Server B → 8 CPU / 16 GB
Server C → 2 CPU / 4 GB

Sending roughly 33% of traffic to each server probably isn't what you want.

That's where Weighted Round Robin helps.

A → Weight 4
B → Weight 4
C → Weight 1

The stronger servers receive more traffic.

Better.

But there's still a problem.

Weights describe what a server is expected to handle.

They don't necessarily describe what it can handle right now.

Server A could currently be:

CPU:         94%
Memory:      87%
Connections: 143

while Server B is sitting comfortably at 30%.

A static rotation doesn't inherently understand that.

So We Need Smarter Algorithms?

Sometimes.

Least Connections, for example, considers how many active connections each server currently has.

Instead of asking:

Whose turn is next?

we're asking:

Who looks least busy right now?

That's often more useful when request duration varies significantly.

But even that isn't perfect.

10 lightweight requests

could consume fewer resources than:

2 expensive requests

Which reveals the real problem.

What Does "Load" Actually Mean?

This is the question I think matters more than:

"Which load-balancing algorithm should I use?"

Ask:

What does load mean for this particular system?

Maybe it's:

CPU usage
Memory pressure
Active connections
Request latency
Queue depth
Database pressure
Downstream dependency latency

Or a combination of them.

Because you can have perfectly balanced application servers while something downstream is burning:

Server A ─┐
Server B ─┼──────► Database 🔥
Server C ─┘

Your load balancer says everything is fine.

Your database strongly disagrees.

Round Robin Isn't Bad

This is important.

Round Robin is not a bad algorithm.

For stateless services with similar instances and reasonably predictable requests, its simplicity can be a major advantage.

Simple systems are easier to understand, operate and debug.

The mistake isn't using Round Robin.

The mistake is assuming:

Equal Requests = Equal Load

without checking whether that's actually true for your workload.

The Part Worth Remembering

Load balancing is really a scheduling decision:

Where should the next piece of work go?

Round Robin answers:

"Who's next?"

Weighted Round Robin asks:

"Who's next, considering capacity?"

Least Connections asks:

"Who's least busy?"

More adaptive approaches can ask:

"Who looks healthiest right now?"

There isn't one universally correct answer.

It depends on what you're trying to balance.

So next time your architecture diagram looks like this:

              Load Balancer
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
          A         B         C
         33%       33%       33%

don't just ask:

"Is traffic evenly distributed?"

Ask:

"What exactly did we balance?"

That's usually where the more interesting system-design conversation begins.

How to Choose Between SQL, NoSQL, and Everything in Between

Sanu Khan — Tue, 25 Aug 2026 06:57:45 +0000

System Design from Developer to Architect — Part 2

In Part 1, we took a backend from:

User → Application → Database

to something much larger:

Users
  ↓
CDN
  ↓
Load Balancer
  ↓
API Cluster
  ↓
Cache + Database
  ↓
Read Replicas
  ↓
Event Broker

We scaled application servers.

We introduced caching.

We added read replicas.

We moved static content to the edge.

We pushed non-critical work into asynchronous processing.

Then someone asks:

Should we move to NoSQL?

It's one of the most common questions in system design.

But it's usually the wrong first question.

A better question is:

What problem are we trying to solve with our data?

Because database architecture shouldn't begin with:

SQL vs NoSQL

It should begin with:

Data
  ↓
Access Pattern
  ↓
Consistency Requirement
  ↓
Scale
  ↓
Constraints
  ↓
Storage Decision

Let's work through it.

Start With the Boring Choice

Suppose we're still building the service-booking platform from the previous articles.

Our core data looks something like this:

User
  │
  ▼
Booking
  │
  ├──── Professional
  │
  └──── Payment

We need to answer questions such as:

Who created this booking?

Which professional owns the slot?

Has the booking been paid?

What is the booking status?

These entities have clear relationships.

A relational database is a natural starting point.

              ┌───────────┐
              │   Users   │
              └─────┬─────┘
                    │
                    ▼
              ┌───────────┐
              │ Bookings  │
              └─────┬─────┘
                    │
             ┌──────┴──────┐
             ▼             ▼
      Professionals     Payments

PostgreSQL, MySQL, or another relational database gives us useful capabilities immediately:

Transactions
Foreign keys
Unique constraints
Indexes
Joins
Mature query tooling
Strong data-integrity mechanisms

For many systems, that's an excellent default.

You don't need NoSQL simply because your application might become large.

Relationships Matter

Consider a booking.

Booking
  │
  ├── belongs to → User
  │
  ├── reserves → Professional
  │
  └── has → Payment

Now imagine two customers attempt to reserve the same professional and time slot.

Our database may need to protect something like:

professional_id + booking_date + start_time

from being booked twice.

A relational database can enforce important invariants close to the data.

For example:

UNIQUE (
  professional_id,
  booking_date,
  start_time
)

Application code can contain bugs.

Two application servers can race.

Requests can arrive simultaneously.

The database can still protect the invariant.

This is one reason database choice isn't only about performance.

It's also about correctness.

Then the Data Stops Looking So Relational

Now our professional profiles become more complicated.

A cleaner may have:

{
  "equipment": ["vacuum", "steam cleaner"],
  "languages": ["English", "Arabic"],
  "serviceArea": ["Dubai Marina", "JLT"]
}

A salon professional might have:

{
  "specialties": ["hair", "nails"],
  "certifications": ["CERT-123"],
  "products": ["Brand A", "Brand B"]
}

A maintenance professional may need completely different attributes.

Now our data becomes more flexible.

One option is still relational storage.

Modern relational databases can support JSON columns and hybrid models very effectively.

Another option, depending on the workload, is a document database.

Professional
      │
      ▼
┌────────────────────────┐
│ Document               │
│                        │
│ name                    │
│ services[]              │
│ languages[]             │
│ certifications[]        │
│ metadata{}              │
└────────────────────────┘

The question isn't:

"Is MongoDB better than PostgreSQL?"

The question is:

Does our access pattern benefit enough from a document model to justify another storage technology?

Think in Access Patterns

This is one of the most important ideas in database design.

Don't ask only:

What does my data look like?

Also ask:

How will the application access it?

Suppose we frequently perform:

session_id
    ↓
session

or:

token
  ↓
metadata

or:

user_id
   ↓
preferences

These are simple key-based access patterns.

KEY
 │
 ▼
VALUE

For workloads dominated by this kind of lookup, a key-value store can be extremely effective.

Conceptually:

session:8fa92
      │
      ▼
┌─────────────────────┐
│ userId: 123         │
│ expires: 10:30      │
│ permissions: [...]  │
└─────────────────────┘

This is why systems often use Redis or distributed key-value databases for particular workloads.

Not because:

"NoSQL is faster."

But because the access pattern matches the storage model.

Search Is a Different Data Problem

Now users want to search for:

Female cleaner near Dubai Marina, available tomorrow morning, rated above 4.5.

Suddenly we're dealing with combinations of:

Text
Location
Availability
Rating
Filters
Sorting

We could continue pushing increasingly complex search queries into the primary database.

But at some point, search itself becomes a specialized workload.

We may introduce a search index:

              Primary Database
                     │
                     │ index/update
                     ▼
               Search Engine
                     │
                     ▼
                 Search API
                     │
                     ▼
                   User

The primary database remains the source of truth.

The search engine provides a representation optimized for discovery.

Now we can optimize for:

Full-text search
Relevance ranking
Faceted filters
Fuzzy matching
Geospatial queries

But we've created another problem.

What if:

Database
Professional rating = 4.8

Search Index
Professional rating = 4.6

The index hasn't caught up yet.

Our search system may now be eventually consistent.

Once again:

Problem
   ↓
Specialized solution
   ↓
New trade-off

Not Every Relationship Needs a Graph Database

Our platform keeps growing.

Now we have relationships such as:

User
 │
 ├── booked ──────→ Professional
 │
 ├── likes ───────→ Service
 │
 └── referred ────→ User
                       │
                       └── booked ──→ Professional

Maybe we want to answer:

Which professionals are popular among users connected to this customer?

Or:

Which services are commonly booked together across several degrees of relationships?

Highly connected traversal can become an interesting graph problem.

A graph model represents information as:

Node ── Relationship ── Node

For example:

        BOOKED
User ─────────────→ Professional
 │
 │ LIKES
 ▼
Service
 │
 │ RELATED_TO
 ▼
Service

A graph database may make complex relationship traversal natural.

But this does not mean:

We have relationships
       ↓
Use graph database

Relational databases already handle relationships extremely well.

Graph databases become interesting when relationship traversal itself becomes a dominant access pattern.

Files Don't Belong Everywhere Either

Our application also stores:

Profile photos
Invoices
Documents
Videos
Attachments
Exports

Should these live directly inside our relational database?

Sometimes binary data can be stored there.

But for large files and media, object storage is often a better fit.

Application
    │
    ├──── Metadata ────→ Database
    │
    └──── File ────────→ Object Storage

The database might store:

file_id
owner_id
object_key
content_type
created_at

while object storage holds the actual binary content.

Again, different data characteristics create different storage requirements.

Now We Have Multiple Databases

Our simple architecture started as:

Application
     │
     ▼
Database

Now it might look like this:

                       Application
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
          ▼                 ▼                 ▼
     Relational           Redis            Search
      Database             │                 │
          │             Sessions          Discovery
      Bookings            Cache             Text
      Payments                              Filters
          │
          └─────────────────┐
                            │
                            ▼
                       Object Storage
                       Files / Media

Potentially, another specialized workload may justify a document or graph database.

This is called polyglot persistence.

But be careful.

Polyglot persistence does not mean:

"Use every database."

It means:

Allow different storage technologies when different data problems justify the operational complexity.

Every database you add creates costs:

Another database
      │
      ├── Deployment
      ├── Monitoring
      ├── Backups
      ├── Security
      ├── Access control
      ├── Data synchronization
      ├── Developer knowledge
      └── Failure modes

Sometimes one PostgreSQL database is better than five specialized systems.

Consistency Changes the Decision

Database choice isn't only about data shape.

It's also about how correct the data must be at a particular moment.

Consider:

Booking confirmed?
Payment completed?
Slot available?

These decisions may require strong guarantees.

Now compare them with:

Analytics dashboard
Search results
Recommendations
Activity feed

If analytics is 10 seconds behind, the business may barely notice.

If booking availability is 10 seconds behind, two customers may try to buy the same slot.

So we can think about data differently:

Booking / Payment
       │
       ▼
Correctness critical
       │
       ▼
Stronger consistency

versus:

Analytics / Search
       │
       ▼
Temporary staleness acceptable
       │
       ▼
Eventual consistency may work

Consistency should follow business correctness requirements—not architecture fashion.

CAP Theorem Without the Interview Definition

You'll eventually hear:

CAP theorem.

The textbook definition matters.

But let's make the architectural problem concrete.

Imagine our database is distributed across two nodes.

        Network
          ✕
     ┌────┴────┐
     ▼         ▼
  Node A     Node B

The nodes can no longer communicate.

But requests are still arriving.

Now the system has a decision to make.

Should both nodes continue accepting operations even though they may temporarily disagree?

Or should some operations be rejected until the nodes can communicate again?

Conceptually:

Network Partition
       │
       ├── Preserve stronger consistency
       │       ↓
       │   Some requests may fail
       │
       └── Preserve availability
               ↓
          Nodes may temporarily disagree

That's the practical architectural tension.

The important lesson isn't memorizing:

C + A + P

It's understanding:

What should our system do when parts of the distributed data layer cannot communicate?

Build the Decision From Requirements

Instead of beginning with database products, start with questions.

What does the data need?
          │
          ├── Transactions?
          │       └── Relational
          │
          ├── Simple key lookup?
          │       └── Key-Value
          │
          ├── Flexible documents?
          │       └── Document
          │
          ├── Full-text discovery?
          │       └── Search
          │
          ├── Relationship traversal?
          │       └── Graph
          │
          └── Large binary objects?
                  └── Object Storage

This is not an automatic decision tree.

It's a way to start asking better questions.

Before choosing storage, ask:

What does the data look like?
How will it be accessed?
What are the read/write ratios?
Which operations require transactions?
How much staleness is acceptable?
How large can the dataset become?
What are the expected query patterns?
What happens during failure?
What operational complexity can the team support?

Then evaluate technologies.

Not the other way around.

The Database Architect's Loop

The same mental model we've used throughout this series still works.

Data Requirement
       ↓
Access Pattern
       ↓
Consistency Requirement
       ↓
Scale Requirement
       ↓
Storage Options
       ↓
Trade-offs
       ↓
Decision
       │
       └──────────────↺

We didn't choose a relational database because:

"SQL is better."

We didn't introduce Redis because:

"Redis is fast."

We didn't introduce a search engine because:

"Databases can't search."

Each technology entered the architecture because the workload developed a specific requirement.

So... SQL or NoSQL?

The answer is frustratingly simple:

It depends on the problem.

But now we can make "it depends" useful.

Requirement	Storage Model to Evaluate
Transactions and relational integrity	Relational
Flexible nested documents	Document
Extremely simple key-based access	Key-Value
Full-text search and ranking	Search engine
Complex relationship traversal	Graph
Large files and media	Object storage

And sometimes the correct answer is:

PostgreSQL.

Sometimes:

PostgreSQL + Redis.

Sometimes:

PostgreSQL
   +
Redis
   +
Search Index
   +
Object Storage

The goal isn't to collect databases.

The goal is to use the smallest set of storage technologies that correctly supports the workload.

Don't Choose the Database First

A common mistake looks like this:

"We want MongoDB."
       ↓
"What can we store in it?"

or:

"We should use Redis."
       ↓
"What should we cache?"

Reverse it:

Requirement
    ↓
Data Shape
    ↓
Access Pattern
    ↓
Consistency
    ↓
Scale
    ↓
Trade-offs
    ↓
Technology

That's architecture.

The technology comes after the reasoning.

The Real Goal

The question isn't:

SQL or NoSQL?

The better questions are:

What does this data represent?

How will we access it?

How correct must it be?

How will it scale?

What happens when the system fails?

And is another database worth the operational complexity it introduces?

If one relational database solves those problems, keep it.

If the workload develops a specialized requirement, introduce the appropriate tool.

But make every database earn its place in the architecture.

Up Next

Our data layer is evolving.

Our application is scaling.

Now another boundary starts becoming critical:

Client
  │
  ▼
 API
  │
  ▼
System

APIs that look perfectly reasonable at small scale can become difficult to evolve as clients, services, and integrations multiply.

So next we'll look at:

Part 3 — How to Design APIs That Don't Fall Apart as Your System Grows

We'll cover:

REST boundaries
Resource design
Pagination
Filtering
Versioning
Idempotency
Rate limiting
API gateways
Synchronous vs asynchronous communication
Service-to-service APIs

This is **Part 2* of System Design from Developer to Architect — a practical series about scalability, databases, APIs, distributed systems, reliability, and the engineering decisions behind production architecture.*

Previous: Part 1 — How to Scale a Backend From 1 User to 1 Million Users

Series: System Design from Developer to Architect

How to Scale a Backend From 1 User to 1 Million Users

Sanu Khan — Tue, 18 Aug 2026 10:40:01 +0000

System Design from Developer to Architect --- Part 1

In Part 0, we started with a simple rule: don't add architecture
because it looks scalable. Add it when a real problem makes it
necessary.

In this part, we'll start with one user, keep adding traffic, and
change the architecture only when something gives us a reason to.

Previous: Part 0 --- How to Think About System Design Without Just
Drawing
Boxes

A million users sounds like a completely different engineering problem
from one user.

And eventually, it is.

But the interesting part isn't the final architecture.

It's how we get there.

We won't begin with CDN, Redis, replicas, event brokers, and a cluster
of services.

We'll begin here:

User → Application → Database

Then we'll keep increasing traffic.

Every time something becomes a real constraint, we'll ask:

What broke, why did it break, and what is the smallest architectural
change that solves it?

That's the scaling journey.

Stage 1 --- 1 User: Keep It Boring

Imagine we've just launched a service-booking application.

One user opens the application, searches for a professional, checks a
slot, and creates a booking.

Our architecture can be extremely simple:

User
 │
 ▼
Application
 │
 ▼
Database

And that's enough.

No Redis. No Kafka. No Kubernetes. No read replicas.

There is nothing wrong with this architecture.

In fact, adding distributed infrastructure now would probably make the
system harder to build, deploy, debug, and operate without solving a
real problem.

The cheapest scaling problem is the one you don't have yet.

Stage 2 --- 100 Users: The Simple Architecture Still Works

Now we have 100 users.

Do we need microservices? Probably not.

Do we need Kafka? Probably not.

At this stage, the highest-value improvements are often much less
exciting:

Add the right database indexes
Fix inefficient queries
Avoid N+1 queries
Use database connection pooling
Compress HTTP responses
Handle static assets efficiently
Add basic metrics and logs
Measure latency before optimizing it

A surprisingly large amount of scale can come from simply making the
existing system efficient.

Sometimes:

Slow API
   ↓
Fix query / index
   ↓
Fast API

is a better scaling strategy than adding another server.

Before distributing the system, make the simple system efficient.

Stage 3 --- 10,000 Users: Scale Up Before Scaling Out

Traffic keeps growing.

Now we start seeing resource pressure:

CPU       78%
Memory    82%
p95       650ms
Traffic   ↑

The first response doesn't always need to be horizontal scaling.

We might simply give the machine more resources:

2 CPU   →   8 CPU
4 GB    →   32 GB RAM

That's vertical scaling.

It's simple because our architecture barely changes.

Vertical scaling can take us surprisingly far.

But machines don't grow forever, and a single server remains a single
failure domain.

Eventually, traffic may exceed what one instance can comfortably handle.

That's when the second server becomes interesting.

Stage 4 --- 50,000 Users: The Second Server Changes Everything

Eventually one application instance isn't enough.

So we add another.

Now we need something to decide where incoming requests should go.

Enter the load balancer.

                 Users
                   │
                   ▼
            Load Balancer
                   │
            ┌──────┴──────┐
            ▼             ▼
          App 1         App 2
            │             │
            └──────┬──────┘
                   ▼
                Database

Now we can scale horizontally by adding application instances.

But this works cleanly only when those instances are interchangeable.

And that creates our next problem.

The State Problem

Suppose the user logs in through App 1.

Their session is stored in that server's memory.

Their next request reaches App 2.

Login → App 1
Session stored locally

Next request → App 2
Session = ?

The load balancer did exactly what we asked.

Our application architecture didn't.

This is why horizontal scaling often pushes us toward stateless
application servers.

For shared session state, Redis is one possible solution:

              Load Balancer
                    │
           ┌────────┴────────┐
           ▼                 ▼
         App 1             App 2
           │                 │
           └────────┬────────┘
                    ▼
                  Redis
                    │
                    ▼
                 Database

Notice the sequence:

More traffic
    ↓
More instances
    ↓
Requests move between instances
    ↓
Local state becomes a problem
    ↓
Shared/stateless state becomes useful

Redis didn't appear because Redis is fashionable.

It appeared because the architecture developed a state problem.

Stage 5 --- 100,000 Users: Repeated Reads Start to Hurt

Some requests repeatedly fetch the same information:

GET /services
GET /categories
GET /professionals/123

If that data changes infrequently, sending every request to the database
is wasteful.

Now caching has a concrete job.

Request
   │
   ▼
Application
   │
   ▼
 Cache
  / \
HIT MISS
 │    │
 ▼    ▼
Return DB
       │
       ▼
     Cache
       │
       ▼
     Return

A cache hit avoids an unnecessary database read.

A cache miss falls back to the source of truth.

This reduces latency and database pressure.

But caching introduces new concerns:

TTL
Invalidation
Eviction
Stale data
Cache stampedes
Failure behavior

For a service description, some staleness may be acceptable.

For the last available booking slot, it may not be.

Caching isn't just a performance decision. It's also a correctness
decision.

Stage 6 --- 250,000 Users: The Bottleneck Moves

The API tier looks healthy.

Then monitoring shows:

API CPU             35%   ✓
API Memory          42%   ✓

DB CPU              92%   ⚠
DB Connections      95%   ⚠
p95 Query Latency   780ms ⚠

Should we add another API server?

No.

The API isn't the bottleneck anymore.

The bottleneck moved.

App 1 ──┐
App 2 ──┤
App 3 ──┼────> DATABASE 🔥
App 4 ──┤
App 5 ──┘

A struggling database does not immediately mean:

"We need sharding."

Start with evidence:

Database pressure
       │
       ├── Inspect slow queries
       ├── Verify indexes
       ├── Remove N+1 access
       ├── Reduce unnecessary reads
       ├── Cache appropriate data
       ├── Review connection usage
       └── Then consider infrastructure scaling

A bad query executed across ten replicas is still a bad query.

Scale the bottleneck only after understanding the bottleneck.

Stage 7 --- 500,000 Users: Separate Reads From Writes

Suppose our workload is heavily read-oriented.

Users browse much more often than they modify data.

We may introduce read replicas:

                    Application
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
            Writes                 Reads
              │                     │
              ▼                     ▼
           Primary             Read Replicas
                                  │      │
                                  ▼      ▼
                              Replica  Replica

Writes continue to go to the primary.

Read-heavy traffic can be distributed across replicas.

But we've bought a new problem:

Replication Lag

Replication is not always instantaneous.

A user may create a booking on the primary and immediately read from a
replica that hasn't received the update yet.

The system scaled.

Consistency became more complicated.

Problem
  ↓
Solution
  ↓
New Trade-off

Stage 8 --- 750,000 Users: Stop Sending Everything Through the Backend

Images, JavaScript bundles, CSS, downloads, and other static assets
don't necessarily need to travel through application servers on every
request.

A CDN can move cacheable content closer to users.

                  Users
                    │
            ┌───────┴────────┐
            ▼                ▼
           CDN          Load Balancer
            │                │
      Static Content      API Servers

This reduces:

Origin traffic
Backend bandwidth
Static-content latency
Unnecessary application-server work

Again, the CDN has a reason to exist.

Stage 9 --- 1 Million Users: Stop Doing Everything Synchronously

Consider what happens when someone creates a booking.

Our API might perform:

Create Booking
      ↓
Send Email
      ↓
Send Push Notification
      ↓
Update Analytics
      ↓
Award Loyalty Points
      ↓
Notify Professional
      ↓
Return Response

The customer is waiting for work that doesn't necessarily need to finish
before the booking is acknowledged.

The core path may only require:

Validate
   ↓
Reserve
   ↓
Persist
   ↓
Confirm

Other work can happen asynchronously:

             Booking Service
                    │
                    ▼
              BookingCreated
                    │
                    ▼
               Event Broker
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     Notify     Analytics     Loyalty

This improves responsiveness and decouples downstream work.

But now we need to think about:

Duplicate events
Consumer failures
Ordering
Retries
Dead-letter queues
Database/event consistency

For example:

Database COMMIT   ✓
Event publish     ✗

That's not just a messaging problem.

It's a consistency problem.

We'll explore that later in the series.

What Did We Actually Build?

We started here:

User → Application → Database

And ended somewhere closer to this:

                         Users
                           │
                           ▼
                          CDN
                           │
                           ▼
                     Load Balancer
                           │
                ┌──────────┼──────────┐
                ▼          ▼          ▼
              API 1      API 2      API 3
                │          │          │
                └──────────┼──────────┘
                           │
                   ┌───────┴────────┐
                   ▼                ▼
                 Cache          Database
                                   │
                          ┌────────┴────────┐
                          ▼                 ▼
                     Replica 1         Replica 2
                                   │
                                   ▼
                              Event Broker
                                   │
                         ┌─────────┼─────────┐
                         ▼         ▼         ▼
                       Worker   Notify   Analytics

That's a much more sophisticated architecture.

But here's the important part:

We didn't start by designing this architecture. We arrived at it.

Every component earned its place.

One Million Users Didn't Create One Scaling Problem

It created a sequence of different problems.

Growth Stage What Starts Hurting Architectural Response

1--100 Nothing significant Keep it simple

100--10K Inefficient Optimize and scale
code/queries, resource vertically
pressure

10K--50K Single-server capacity Horizontal scaling +
load balancing

50K--100K Instance-local state Stateless services /
shared state

100K--250K Repeated expensive Caching
reads

250K--500K Database pressure Query optimization +
read scaling

500K--750K Origin/static-content CDN / edge delivery
load

750K--1M Too much synchronous Async processing /
work event-driven workflows

These user counts are illustrative, not universal thresholds.

A read-heavy application may hit database limits much earlier.

A compute-heavy application may hit CPU limits first.

A media platform may need a CDN almost immediately.

A financial system may prioritize consistency and transaction boundaries
long before raw traffic becomes interesting.

Scale is workload-specific.

Don't Scale Users. Scale Bottlenecks.

You don't actually scale because you reached:

100,000 users

You scale because something measurable changed:

CPU              ↑
Memory           ↑
Connections      ↑
Queue depth      ↑
Database latency ↑
Error rate       ↑
p95 / p99        ↑

User count is context.

Resource pressure and system behavior tell you what needs to change.

Two applications with one million users can require completely different
architectures.

The Scaling Loop

The mental model from Part 0 still applies:

Traffic grows
     ↓
Observe
     ↓
Find bottleneck
     ↓
Understand cause
     ↓
Choose solution
     ↓
Measure again
     ↓
Repeat

Not:

Traffic grows
     ↓
Add every technology we know

That difference is where architecture starts becoming engineering.

The Real Goal

The goal isn't to build a one-million-user architecture on day one.

The goal is to build a system that:

Works for today's requirements
Is observable enough to tell you what is breaking
Has clear boundaries where change is likely
Can evolve when the next constraint appears

A three-box architecture that correctly serves your current workload is
better than a fifteen-service architecture whose complexity you don't
need.

Start simple.

Measure.

Find the bottleneck.

Solve that bottleneck.

Then repeat.

Don't design for one million users on day one. Design a system that
gives you a clear path to the next stage.

Up Next

We've spent this article scaling application infrastructure.

But eventually, almost every system-design discussion reaches another
question:

What database should we actually use?

SQL? NoSQL? Document? Key-value? Graph?

More importantly:

How do we choose without starting from technology hype?

Next → Part 2

How to Choose Between SQL, NoSQL, and Everything in Between

This is **Part 1* of System Design from Developer to Architect ---
a practical series about scalability, databases, APIs, distributed
systems, reliability, and the engineering decisions behind production
architecture.*

Previous: Part 0 --- How to Think About System Design Without Just
Drawing
Boxes

How to Think About System Design Without Just Drawing Boxes

Sanu Khan — Fri, 14 Aug 2026 11:03:14 +0000

System design isn't about drawing more boxes. It's about knowing when the next box becomes necessary.

Most system-design diagrams eventually look something like this:

Load balancer. Redis. Kafka. Replicas. CDN. Microservices.

It certainly looks like system design.

But remove the labels and ask one question:

Why does each box exist?

That's where things become interesting.

If the answer is:

"Because scalable architectures use Redis."

or:

"Kafka is good for microservices."

or:

"We need Kubernetes because this is production."

then we aren't really designing a system.

We're assembling technologies.

Modern system design is much more about reasoning through change:

And that is what this series is about.

Welcome to System Design from Developer to Architect.

Start With Almost Nothing

Imagine we're building a service-booking platform.

Customers need to:

find a professional,
check availability,
reserve a time slot,
pay,
receive confirmation.

There are ten users.

What architecture do we need?

Probably this:

That's it.

No Redis.

No Kafka.

No Kubernetes.

No microservices.

And that's not an amateur architecture.

For the requirements we currently know, it may be exactly the right architecture.

Good architecture is not the architecture with the most components. It's the architecture with the least unnecessary complexity.

Then Traffic Arrives

Our product starts getting traction.

The server that happily handled a few hundred requests is now struggling.

Now we have a problem.

And importantly:

we had the problem before we introduced the solution.

That's how I like to approach system design.

Instead of:

Technology → Find somewhere to use it

we want:

Problem → Constraints → Options → Decision

Our first option might simply be a larger server.

4 CPU  →  16 CPU
8 GB   →  64 GB RAM

Vertical scaling.

Simple.

Often effective.

But eventually we may want to run multiple application instances.

And the moment we do that, our architecture changes.

The Second Server Changes Everything

We go from:

Why did the load balancer appear?

Not because:

"Architectures should have load balancers."

It appeared because we now have multiple application instances and need to distribute requests between them.

One box.

One reason.

But our solution immediately creates another problem.

Wait... Where Did My Session Go?

Imagine authentication sessions are stored in application memory.

The user logs in:

Login
  │
  ▼
App 1

Session stored in App 1

Next request:

GET /bookings
      │
      ▼
    App 2

"Who are you?"

The load balancer did its job perfectly.

Our architecture didn't.

Horizontal scaling has exposed a state problem.

Now we have architectural choices.

We could make the application stateless.

Or introduce shared session storage.

For example:

Redis finally enters our architecture.

But notice the sequence:

More traffic
    ↓
Multiple servers
    ↓
Requests move between servers
    ↓
Local session state becomes problematic
    ↓
Need shared/distributed state
    ↓
Redis becomes one possible solution

That's very different from starting the architecture with Redis because "Redis is fast."

The Bottleneck Moves

We add more application servers.

Everything looks scalable.

Until the dashboard says:

API CPU             35%   ✓
API memory          42%   ✓

DB CPU              94%   ⚠
DB connections      97%   ⚠
Query latency       850ms ⚠

Adding another API instance isn't going to save us.

Our bottleneck moved.

This is an important mental model:

Scaling doesn't eliminate bottlenecks. It moves them.

Maybe the problem is missing indexes.

Maybe we're making unnecessary queries.

Maybe one expensive query dominates database time.

Maybe we need caching.

Maybe reads need replicas.

Maybe our data model is wrong.

The architecture should not answer those questions before the evidence does.

Enter the Cache

Suppose profiling reveals something interesting.

Thousands of requests repeatedly fetch information that barely changes:

GET /services

GET /categories

GET /professionals/123

Every request goes to the database.

Now caching has a concrete job.

Great.

Latency drops.

Database traffic drops.

Everyone celebrates.

Until this happens.

Fast and Wrong Is Still Wrong

A professional has one remaining slot:

10:00 AM → AVAILABLE

The database says:

10:00 AM → AVAILABLE

The cache says:

10:00 AM → AVAILABLE

Customer A books it.

The database becomes:

10:00 AM → BOOKED

But for a short period, the cache still says:

10:00 AM → AVAILABLE

Customer B sees the stale value.

Our system is faster.

But it may now be showing incorrect availability.

This is the other half of architecture that diagrams often hide.

Every solution comes with a bill.

Cache
  │
  ├── + Lower latency
  ├── + Lower DB load
  │
  ├── - Stale data
  ├── - Invalidation
  ├── - Stampedes
  └── - Additional failure mode

The interesting question isn't "Should we use Redis?"

It's:

"Which data are we willing to serve stale, and for how long?"

That is a much more useful architecture discussion.

Then Someone Says, "Let's Add Kafka"

Eventually, our booking workflow grows.

When a booking succeeds we need to:

Create booking
      │
      ├── Send email
      ├── Send push notification
      ├── Update analytics
      ├── Award loyalty points
      └── Notify professional

Should the customer wait while every one of those operations completes?

Probably not.

Now asynchronous processing becomes attractive.

Kafka, RabbitMQ, SQS or another messaging system might now solve a real problem.

But we just bought ourselves another collection of problems.

What if the same event arrives twice?

What if events arrive out of order?

What if the consumer crashes?

What if processing fails repeatedly?

What if the booking commits to the database but publishing BookingCreated fails?

Database COMMIT   ✓

Event publish     ✗

That's a tiny diagram containing a very large distributed-systems problem.

We'll get to it later in this series.

Architecture Is a Sequence, Not a Snapshot

This is why I think one giant "final architecture" diagram is often a poor way to learn system design.

It shows where the system ended up.

It doesn't explain how it got there.

A better way is to watch the architecture evolve.

The final diagram is not the lesson.

The transitions are.

Use This Framework for Every Architecture Decision

For every new box we introduce in this series, we'll ask five questions.

1 — What changed?

Traffic?

Data volume?

Availability requirement?

Latency requirement?

Business workflow?

2 — What broke?

CPU?
Memory?
Database?
Network?
Consistency?
Reliability?
Developer velocity?

3 — What options do we have?

There should usually be more than one.

4 — Why are we choosing this option?

This is where trade-offs matter.

5 — What new failure modes did we introduce?

This is the question people skip.

And it's often the most important one.

Every Box Has a Cost

Here's a useful way to look at common architecture components.

We add...	Because we need...	But now we must think about...
Load Balancer	Horizontal scaling	Health checks, routing, failure detection
Redis	Lower latency / shared state	Staleness, eviction, invalidation
Read Replicas	More read capacity	Replication lag
CDN	Lower global latency	Cache invalidation
Message Broker	Async workflows	Duplicates, ordering, retries
Microservices	Independent boundaries	Network failures, distributed transactions
Retries	Resilience to transient failure	Duplicates, retry storms
Sharding	Larger data scale	Routing, rebalancing, cross-shard operations

Architecture becomes much easier to reason about when we stop seeing components as features and start seeing them as trade-offs.

Think About the Failure Path

Developers naturally focus on this:

Request
   ↓
Process
   ↓
Success

Architectural thinking requires another diagram.

Request
   │
   ├── Success
   │
   ├── Timeout
   │
   ├── Partial success
   │
   ├── Dependency unavailable
   │
   ├── Duplicate request
   │
   └── Concurrent request

Consider our booking platform.

Two customers click the same slot at almost exactly the same time.

Who gets the slot?

Now we're talking about concurrency.

Maybe transactions.

Maybe optimistic locking.

Maybe pessimistic locking.

Maybe a database constraint.

Maybe temporary reservations.

The correct answer depends on our requirements.

Now Make Payment Fail

Our booking workflow becomes:

Reserve Slot
     │
     ▼
Create Booking
     │
     ▼
Charge Payment
     │
     ▼
Confirm Booking

Happy path?

Easy.

Now:

Reserve Slot       ✓

Create Booking     ✓

Charge Payment     ✓

Confirm Booking    ✗

The customer's card has been charged.

But their booking isn't confirmed.

What now?

Retry?

Refund?

Compensate?

Reconcile later?

And what happens if the payment API timed out?

If we blindly retry, we might charge the customer twice.

Suddenly a seemingly simple requirement—

"Let customers pay."

—has led us to idempotency.

This is what makes system design interesting.

Stop Asking "What Technology Should I Use?"

Try replacing technology questions with engineering questions.

Instead of:

Should I use Kafka?

Ask:

Do these operations need to happen synchronously?

Instead of:

Should I use Redis?

Ask:

Which reads are expensive, repetitive and safe to cache?

Instead of:

Should I use microservices?

Ask:

Which domains need independent ownership, deployment or scaling?

Instead of:

Should I use NoSQL?

Ask:

What are my access patterns, consistency requirements and data relationships?

Instead of:

Should I use Kubernetes?

Ask:

What deployment and orchestration problems do I actually have?

The quality of the architecture usually improves when the quality of the question improves.

The Architect's Loop

The mental model we'll use throughout this series is simple:

You don't finish architecture.

You continuously make better decisions as the system changes.

What We're Going to Build in This Series

We're going to start here:

User
 │
 ▼
Server
 │
 ▼
Database

And gradually evolve toward something closer to:

But we're not going to jump directly there.

We'll earn every box.

We'll encounter the problem first.

Then introduce the concept.

Then look at the solution.

Then deliberately try to break it.

Where We're Going

The first part of this series will build the foundations:

Single Server
     ↓
Database
     ↓
Vertical Scaling
     ↓
Horizontal Scaling
     ↓
Load Balancing
     ↓
Caching
     ↓
API Design
     ↓
Communication Protocols
     ↓
Authentication
     ↓
Authorization
     ↓
Security

Then we'll move into the problems that make production systems interesting:

Concurrency
     ↓
Transactions
     ↓
Idempotency
     ↓
Retries
     ↓
Event Delivery
     ↓
Distributed Transactions
     ↓
Saga
     ↓
Transactional Outbox
     ↓
Caching & Consistency
     ↓
Observability
     ↓
Resilience

And eventually we'll bring those ideas together in complete system-design case studies.

One Rule Before We Continue

When you see an architecture diagram, don't start by asking:

What technologies are they using?

Start with:

What problem forced this box to exist?

Then ask:

What would happen if I removed it?

And finally:

What new failure modes did adding it create?

If you can answer those three questions for every important component, you're no longer memorizing architecture diagrams.

You're reasoning about systems.

And that's the skill we're going to build.

Up Next: We Add Users Until Something Breaks

We begin with the smallest architecture possible:

User → Server → Database

Then we'll increase the traffic.

1 user
   ↓
100 users
   ↓
10,000 users
   ↓
100,000 users
   ↓
1,000,000 users

At each stage, we'll ask the same question:

What breaks next?

And we'll change the architecture only when we have a reason to.

Next → Part 1

How to Scale a Backend From 1 User to 1 Million Users

This is **Part 0* of System Design from Developer to Architect — a practical series about scalability, databases, APIs, distributed systems and the engineering decisions behind production architecture.*

Suggested DEV.to tags: #systemdesign #architecture #backend #programming

Operational Intelligence: The Missing Nervous System of Modern Business Operations

Sanu Khan — Tue, 19 May 2026 16:22:34 +0000

Why Operational Intelligence (OpsInt) is becoming the foundation of AI-native enterprise systems, autonomous ERP platforms, and intelligent business operations.

Businesses no longer fail because they lack data.

They fail because they cannot understand, correlate, and act on operational signals fast enough.

Introduction

Over the last decade, businesses aggressively digitized their operations.

They adopted:

ERP systems
CRM platforms
HRMS solutions
analytics dashboards
automation workflows
cloud infrastructure
AI copilots
omnichannel communication systems

Yet despite all this technological advancement, many organizations still operate reactively.

Why?

Because most systems are designed to store transactions, not to understand operational behavior in real time.

This is where Operational Intelligence (OpsInt) becomes critically important.

Operational Intelligence is rapidly emerging as the next foundational layer in enterprise architecture — bridging the gap between:

data
automation
observability
AI
business decision-making

In many ways, OpsInt is becoming:

the operational nervous system of modern digital enterprises.

The Problem With Traditional Enterprise Systems

Most businesses today operate through disconnected systems.

For example:

Department	System
Sales	CRM
Finance	ERP
Customer Support	Ticketing System
Operations	Spreadsheets
Marketing	Ad Platforms
Logistics	External Vendor Systems
Communication	Email / WhatsApp / Teams

Each platform stores its own data.

But no system truly understands:

operational relationships
real-time dependencies
business impact
process bottlenecks
behavioral anomalies

As a result:

issues are discovered late
teams operate in silos
workflows break silently
operational risk increases
decisions become reactive

What Is Operational Intelligence?

Operational Intelligence (OpsInt) refers to:

the continuous collection, correlation, monitoring, analysis, and intelligent orchestration of operational data in real time.

Unlike traditional reporting systems that focus on historical analysis, OpsInt focuses on:

live operational visibility
event-driven monitoring
anomaly detection
predictive insights
automated responses
intelligent decision support

The goal is not simply to display dashboards.

The goal is to:

understand operational state continuously
detect problems early
correlate system behavior
optimize workflows
assist or automate operational decisions

Why Operational Intelligence Matters

1. Real-Time Visibility

Traditional BI systems answer:

“What happened?”

Operational Intelligence answers:

What is happening right now?
What requires immediate attention?
What will likely happen next?
What action should be taken?

This transition from historical visibility to live operational awareness is transformative.

2. Event-Driven Decision Making

Modern businesses generate massive streams of operational events:

customer interactions
API requests
inventory updates
payments
approvals
employee activities
logistics movements
system alerts

OpsInt platforms continuously process these events to identify:

operational anomalies
SLA violations
failures
delays
risk patterns
business opportunities

3. Reduced Operational Blind Spots

Many operational failures occur silently:

delayed approvals
failed integrations
unsynced inventory
duplicate records
abandoned leads
infrastructure degradation
delayed customer responses

Operational Intelligence introduces continuous observability across the business ecosystem.

Instead of waiting for customer complaints or revenue impact, the system detects operational friction proactively.

4. AI Requires Operational Context

One of the biggest misconceptions in modern enterprise technology is:

“Adding AI automatically creates intelligent operations.”

In reality, AI without operational context becomes shallow.

For AI systems to generate meaningful recommendations, they require:

real-time operational signals
structured event streams
process awareness
behavioral history
feedback loops
operational memory

Operational Intelligence provides this missing context layer.

It transforms raw enterprise data into actionable operational intelligence.

Operational Intelligence vs Business Intelligence

Business Intelligence	Operational Intelligence
Historical reporting	Real-time operational awareness
Static dashboards	Dynamic event monitoring
Human analysis	Automated reasoning
Strategic reporting	Operational execution
Periodic insights	Continuous intelligence
“What happened?”	“What is happening now?”

Both are important.

But OpsInt extends beyond reporting into operational orchestration.

Why OpsInt Is the Future of ERP Systems

Traditional ERP systems were designed primarily around:

record management
transaction storage
workflow formalization

But modern businesses require much more.

The future ERP will not simply manage records.

It will:

understand operational patterns
predict failures
orchestrate workflows
assist decisions
automate optimization
continuously monitor operational health

In the next generation of enterprise systems, ERP evolves into:

a continuously learning operational intelligence ecosystem.

The Evolution of Enterprise Software

Phase 1 — Digitization

spreadsheets
basic software systems
transaction management

Phase 2 — Automation

workflow automation
integrations
APIs
notifications

Phase 3 — Operational Intelligence

event-driven architecture
anomaly detection
operational observability
predictive workflows

Phase 4 — Autonomous Operations

AI orchestration
self-healing systems
intelligent process optimization
autonomous decision execution

We are currently transitioning from Phase 2 into Phase 3 globally.

Real-World Use Cases of OpsInt

Retail & Commerce

inventory intelligence
pricing synchronization
omnichannel operational visibility

Logistics

route optimization
shipment anomaly detection
predictive delivery monitoring

Finance

fraud monitoring
operational risk analysis
transaction intelligence

SaaS Platforms

infrastructure observability
SLA enforcement
customer operational analytics

Healthcare

patient flow optimization
resource utilization monitoring

Manufacturing

predictive maintenance
production anomaly detection

The Rise of Operational AI

The future of enterprise systems is not merely “AI-generated reports.”

The future is:

operationally aware AI systems capable of understanding business behavior in real time.

This includes:

AI copilots
operational agents
autonomous remediation
intelligent process optimization
self-healing workflows
predictive orchestration

But none of this works reliably without Operational Intelligence as the foundation.

OpsInt becomes the contextual brain layer powering enterprise AI.

Challenges in Building OpsInt Systems

Operational Intelligence is powerful — but technically demanding.

Common challenges include:

data fragmentation
event consistency
tenant isolation
scalability
observability complexity
workflow orchestration
operational governance
AI reliability
latency optimization

This is why many organizations struggle to move beyond isolated automation into true operational intelligence ecosystems.

A New Direction for Enterprise Platforms

A growing number of modern platforms are beginning to move toward this architecture philosophy:

event-driven systems
operational telemetry
workflow orchestration
AI-assisted automation
cross-system intelligence

One conceptual direction exploring these principles is ZaakiyV3RSE — an operational intelligence–oriented ecosystem concept focused on connecting:

workflows
operational observability
automation
AI orchestration
business process intelligence

The broader vision behind such systems is not simply building another SaaS dashboard.

It is about creating:

intelligent operational ecosystems capable of understanding and optimizing business behavior continuously.

Final Thoughts

Operational Intelligence is no longer optional for scaling digital businesses.

As organizations become increasingly:

distributed
API-driven
AI-enabled
event-oriented
automation-heavy

the need for real-time operational understanding becomes critical.

The companies that will dominate the next decade are not necessarily the ones with the most data.

They will be the ones capable of:

understanding operations continuously
correlating operational signals intelligently
automating decisions safely
optimizing systems proactively

Operational Intelligence is the foundation enabling that future.

And over the coming years, it may become as essential to enterprises as ERP and CRM systems became in previous generations.

About the Author

Sanu Khan

Technology Consultant | Solution Architect | Operational Systems Researcher

Focused on:

Operational Intelligence
Enterprise Architecture
AI-Orchestrated Systems
Event-Driven Platforms
Intelligent Business Operations

🌐 Portfolio: https://sanukhan.dev

Footnote

This article explores conceptual and architectural research directions around Operational Intelligence systems, event-driven enterprise architecture, and the future evolution of intelligent ERP ecosystems.

Special mention to the conceptual exploration behind ZaakiyV3RSE, which contributed inspiration toward researching operational intelligence, workflow orchestration, and AI-assisted enterprise operations.

How Claude Code Improved My LinkedIn Profile Visibility !!

Sanu Khan — Mon, 11 May 2026 11:08:41 +0000

A practical 4-minute case study on using Claude Code to review, restructure, and optimise a LinkedIn profile for better visibility, recruiter discovery, and professional positioning.

LinkedIn is no longer just an online resume.

For developers, tech leads, architects, consultants, and product builders, LinkedIn has become a discovery engine. Recruiters search there. Hiring managers validate that. Clients check credibility there. Founders check whether you are serious before starting a conversation.

I already had a LinkedIn profile with my experience, skills, and portfolio links, but I wanted to improve one specific thing:

Visibility.

Not just “make it look better”, but make it easier for the right people to understand what I do, what I have built, and what kind of opportunities I am aligned with.

So I used Claude Code as a profile optimisation assistant.

My LinkedIn profile:

https://www.linkedin.com/in/sanu-khan-dev/

My portfolio website:

https://www.sanukhan.dev/

Why I Used Claude Code for LinkedIn Optimization

Most people use AI tools only for writing captions or generating generic summaries.

I wanted something more practical.

I wanted Claude Code to review my profile like a product page.

A LinkedIn profile has the same structure as a landing page:

The headline is the hero section.
The About section is the product story.
Skills are search keywords.
Featured links are proof of work.
Experience is the case study section.
Recommendations build trust.
The profile photo and banner create the first impression.

That mindset changed how I looked at my profile.

Instead of asking, “Does my profile look good?”, I started asking:

Can someone understand my value in 10 seconds?

That is where Claude Code helped.

Aruvix.com A Private, Offline-First Developer Toolkit for JSON, APIs, QA, and Frontend Utilities

Sanu Khan — Fri, 08 May 2026 06:33:08 +0000

An independent review of Aruvix.com, a browser-local toolkit that combines JSON formatting, API testing, data conversion, QA scaffolding, and frontend utilities into one clean workspace.

Every developer has a version of the same problem.

You are debugging an API response, so you open a JSON formatter. Then you need to decode a token, compare two payloads, generate a UUID, convert JSON to YAML, test a quick request, create fake data, inspect a HAR file, or convert some CSS into Tailwind classes.

Before you realize it, your browser has become a graveyard of random utility tabs.

That is the problem Aruvix.com is trying to solve.

Aruvix positions itself as a unified, browser-based engineering toolkit for developers, QA teams, and technical builders who regularly work with APIs, structured data, frontend utilities, and test scaffolding. After reviewing the platform and its available feature set, the most interesting part is not just the number of tools included. It is the philosophy behind them: keep deterministic developer workflows fast, local, private, and distraction-free.

The Problem: Utility Tab Fatigue Is Real

Most engineers do not open a JSON formatter because they enjoy using a JSON formatter.

They open it because they are in the middle of something else.

Maybe they are debugging a production API issue. Maybe they are checking why a webhook payload failed. Maybe they are comparing a staging response against production. Maybe they are trying to quickly understand what a deeply nested object contains before mapping it into a frontend component.

The task itself is usually simple, but the workflow is fragmented.

A typical debugging session might involve:

One tab for JSON formatting
One tab for JSON comparison
One tab for JWT decoding
One tab for UUID generation
One tab for YAML conversion
One tab for regex testing
One tab for cURL testing
One tab for fake data generation
One tab for API documentation reference
One tab for Jira or GitHub issue formatting

That fragmentation creates a subtle but real cost. You lose focus. You move data between unknown websites. You repeatedly search for tools that should already be part of your workflow.

Aruvix takes a different approach by bringing many of these small but frequent engineering tasks into a single workspace.

The Core Idea: One Local Workspace for Everyday Engineering Tasks

The strongest argument for Aruvix is not that it replaces every specialised tool. It does not need to.

Instead, Aruvix focuses on the 80% of daily developer utility work that should be fast, safe, and immediately available.

It includes tools for:

JSON formatting and repair
JSON comparison
JSON visualization
JSONPath testing
JSON Schema generation
API request testing
cURL import
OpenAPI documentation generation
JavaScript to TypeScript conversion
JSON, XML, YAML, CSV, JSONL, Dart, and TOON conversions
Test data generation
Fake user data generation
Bug report generation
API assertion generation
HAR inspection
UUID generation
Frontend utilities such as CSS-to-Tailwind conversion, color tools, and shadow generation

The value is not only breadth. The value is having these utilities close to each other, especially when the same payload moves through multiple stages of debugging, validation, conversion, and documentation.

Privacy: The Most Important Feature Is What Aruvix Does Not Do

One of the biggest concerns with online developer tools is data privacy.

Developers often paste API responses, logs, tokens, customer records, payment-related payloads, internal IDs, staging data, or production debugging output into random web utilities. Even when the tool looks harmless, that habit can create serious security and compliance risks.

Aruvix addresses this directly with an offline-first, browser-local execution model.

The platform is designed to run locally in the browser with:

No server round-trips for processing
No hidden uploads
No external database tracking for pasted data
No requirement to create an account before using the tools

That matters.

For teams working with proprietary API responses, PII, internal payloads, or customer-facing data, avoiding unnecessary server-side processing is not a minor convenience. It is a practical security improvement.

This is especially relevant for JSON formatting, token decoding, schema generation, payload comparison, and test data workflows where developers often handle sensitive values.

JSON Utilities: The Core Strength of Aruvix

Aruvix appears to treat JSON as a first-class workflow, not just a formatting feature.

That makes sense. JSON is the language of modern APIs, webhooks, frontend-backend contracts, mobile applications, SaaS integrations, and configuration-heavy systems.

JSON Formatter

The JSON Formatter supports beautifying, minifying, validating, and repairing malformed JSON payloads. It also includes syntax-highlighted editing and multiple views, including:

Tree view
Table view
Type view
Raw text view

This is useful because not every JSON task requires the same mental model. Sometimes you want the raw payload. Sometimes you want a collapsible hierarchy. Sometimes you want to inspect data types. Sometimes a table view is the fastest way to understand repeated object structures.

JSON Compare

The JSON Compare tool supports side-by-side structural comparison, path-level difference inspection, and deep nested object diffing.

This is more useful than plain text diffing because JSON changes are often structural rather than textual. A field may move, a nested value may change, an array may include a new object, or a type may shift from number to string.

A path-level diff helps developers answer the question that matters most:

What exactly changed in the payload?

JSON Visualizer

The JSON Visualizer converts deeply nested JSON into interactive node graph views with zoom and pan navigation. It also supports JSONPath inspection for complex structures.

This is valuable when a payload is too nested to understand linearly. For example, large product catalogs, commerce payloads, workflow definitions, CRM objects, permissions trees, analytics responses, and webhook payloads can become difficult to reason about in raw text.

A visual node graph helps developers and QA teams understand the shape of the data before validating or transforming it.

JSON Schema Generator

The JSON Schema Generator can bootstrap starter schemas from sample data, validate JSON against schemas, and generate validation reports.

This is useful for teams that need to formalize API contracts quickly. Instead of manually writing a schema from scratch, developers can start from a sample payload, generate a baseline schema, then refine constraints as needed.

JSON Path Tester

The JSON Path Tester allows users to run JSONPath queries, filter arrays, extract nested values, and highlight matched paths.

This is especially useful when working with large API responses where only a few nested values matter. Instead of manually expanding objects and searching through the payload, JSONPath gives developers a precise query layer over the data.

API Tools: A Lightweight Alternative for Quick Testing

Aruvix includes a lightweight API client for sending HTTP requests and inspecting headers, statuses, and responses locally.

This is not necessarily about replacing a full enterprise API platform. Tools like Postman, Insomnia, Bruno, and Hoppscotch all have their own strengths.

The point of Aruvix is speed and proximity.

When you are already formatting, comparing, validating, or converting payloads, being able to quickly send an HTTP request from the same workspace reduces context switching.

The API tooling includes:

HTTP request testing
Header, status, and response inspection
cURL import
OpenAPI documentation generation from requests
Pre-request and post-request scripting
Environment variables
Request collections
Reusable variables
Proxy support for internal API debugging

cURL Import

cURL import is one of those features that immediately improves real-world usability.

Developers frequently copy cURL commands from browser DevTools, backend logs, API documentation, Slack messages, or issue comments. Being able to paste a cURL command and instantly test it reduces friction.

Screenshot suggestion: Show a cURL command being imported into the API client with method, URL, headers, and body populated automatically.

Environment Management and Scripting

The inclusion of environment variables, request collections, reusable variables, and scripting makes the API client more than a one-off request sender.

Pre-request and post-request scripts are particularly important for workflows that involve tokens, dynamic headers, chained requests, response extraction, or validation logic.

For a browser-local toolkit, this gives Aruvix a more serious API testing foundation.

Code and Data Conversion: Useful for Migration and Integration Work

Modern development often involves translating data between systems, languages, and formats.

Aruvix includes several conversion tools that are useful for integration-heavy workflows.

JavaScript to TypeScript Converter

The JS to TS Converter translates JavaScript into TypeScript with type inference and migration warnings.

This is helpful during gradual TypeScript adoption, refactoring, or when converting utility scripts into more maintainable application code.

Multi-Format Conversion

Aruvix supports bidirectional conversions between:

JSON and XML
JSON and YAML

It also supports exports from JSON to:

CSV
JSONL
Dart
TOON

This combination is useful for developers moving data between APIs, configuration systems, analytics pipelines, AI workflows, mobile app models, and documentation formats.

QA and Testing Scaffolding: A Practical Addition

One of the more interesting parts of Aruvix is that it is not only aimed at developers writing code. It also includes tools that are useful for QA engineers and testers.

The QA and testing utilities include:

Test data generator
Fake user/data generator
Bug report generator
API assertion generator
HAR viewer
UUID generator

Test Data and Fake User Generation

The test data generator and fake user/data generator help quickly create realistic dummy payloads.

This is useful when testing forms, APIs, database imports, dashboards, pagination, search, filtering, validation, and edge cases.

The ability to export generated data as CSV, SQL, or JSON makes it practical for multiple workflows.

Bug Report Generator

The bug report generator formats structured regression reports into Jira or GitHub-friendly Markdown.

This is a smart utility because QA work often suffers not from lack of findings, but from inconsistent reporting. A structured bug report improves reproducibility and reduces back-and-forth between QA and engineering.

API Assertion Generator

The API assertion generator helps create assertions for automated tests.

This can be useful when moving from manual API inspection to repeatable API validation. For example, after inspecting a response manually, a QA engineer or developer can generate starter assertions for status codes, response fields, types, and expected values.

HAR Viewer

The HAR Viewer helps inspect HTTP Archive files for network debugging.

This is particularly useful for frontend developers, QA teams, and support engineers who need to analyze browser network activity, failed requests, redirects, headers, payload sizes, or performance bottlenecks.

Frontend and CSS Utilities: Bridging API Data and UI Work

Aruvix also includes frontend-focused utilities such as:

CSS-to-Tailwind conversion
Color tools
Shadow generators

This might look unrelated to JSON and API tooling at first, but it makes sense in full-stack and frontend-heavy workflows.

Frontend developers often move from API data inspection directly into UI implementation. They may need to inspect response structures, generate mock data, convert styles, test shadows, choose colors, and shape UI states around real payloads.

Having frontend utilities next to data tools helps bridge the gap between backend response inspection and interface development.

Role-Specific Benefits

Aruvix is broad enough to be useful across multiple engineering roles, but its value is slightly different for each group.

For Backend Developers

Backend developers benefit from fast API debugging, secure local payload inspection, JSON validation, schema generation, token-related workflows, and response comparison.

A typical backend workflow might look like this:

Send a request using the API client.
Format the JSON response.
Compare staging and production payloads.
Generate a JSON Schema from the response.
Validate edge-case payloads.
Generate API assertions.
Export examples for documentation or tests.

The key benefit is fewer interruptions during API development and debugging.

For Full-Stack Developers

Full-stack developers often need to move between API contracts, frontend models, UI states, and test data.

Aruvix supports that movement well because it combines API tools, JSON tools, conversion tools, TypeScript utilities, and frontend CSS utilities in one place.

A full-stack developer can inspect an API response, generate a schema, convert sample JavaScript to TypeScript, create dummy data, and use frontend utilities without jumping across several unrelated websites.

For Frontend and UI Developers

Frontend developers benefit from tools that help convert backend data into usable UI structures.

JSON tree views, table views, visualizers, fake data generators, CSS utilities, and TypeScript conversion can all support frontend implementation work.

This is especially useful when designing interfaces before the backend is fully stable or when creating UI states from sample payloads.

For QA Teams

QA teams get value from visual payload inspection, fake data generation, bug report formatting, API assertion generation, HAR viewing, UUID generation, and local validation.

The local-first approach is especially relevant for QA teams handling customer-like test data, internal staging responses, or regression evidence.

Aruvix can help QA move faster without relying entirely on staging servers, engineering support, or separate formatting tools.

For DevOps and Integration Engineers

DevOps and integration engineers often work with structured configuration, webhooks, logs, API responses, YAML, JSON, XML, and environment-specific data.

Aruvix can help with format conversion, request testing, JSONPath extraction, schema validation, and local debugging of payloads that move across systems.

Why Local Execution Matters for AI-Era Development

Aruvix also makes an important point in the age of AI-assisted development.

Not every task needs an LLM.

Formatting JSON, generating a UUID, converting YAML, validating syntax, minifying payloads, comparing objects, or converting data structures are deterministic tasks. They should be instant, predictable, and cheap.

Using AI for these workflows can waste tokens, introduce latency, and sometimes produce inconsistent results. A dedicated local utility is often the better tool.

That does not mean AI is not useful. It means developers should avoid using AI for tasks that are better solved by deterministic local computation.

Aruvix fits into that category: fast, rule-based, local, and purpose-built.

User Experience: Free, No Login, and Ad-Free

Another practical advantage is frictionless access.

Aruvix is free to use, does not require sign-up or login, and presents itself as an ad-free interface.

That matters more than it sounds.

Many utility websites interrupt the workflow with popups, account prompts, ads, cookie banners, or aggressive upsells. For tools developers use during debugging, every unnecessary step adds friction.

Aruvix’s no-login approach makes it easier to use quickly and evaluate honestly.

Where Aruvix Stands Out

After reviewing the feature set, Aruvix stands out in four areas.

1. It Consolidates High-Frequency Developer Utilities

The biggest strength is consolidation. Aruvix brings together many small tools that developers usually access through scattered websites.

2. It Prioritizes Privacy by Keeping Work Local

For production-like payloads, internal data, or sensitive API responses, local processing is a significant advantage.

3. It Serves Multiple Roles Without Feeling Too Narrow

Backend, frontend, QA, full-stack, and DevOps workflows are all represented.

4. It Reduces Context Switching

The platform helps developers stay in the same mental flow while moving between formatting, validation, comparison, conversion, testing, and reporting.

Areas to Watch as the Platform Grows

No review is complete without considering where a tool may need to evolve.

Because Aruvix is broad, discoverability will matter. As more tools are added, the platform needs excellent navigation, search, grouping, keyboard shortcuts, and saved workflows to avoid becoming overwhelming.

For large enterprise workflows, teams may also eventually expect features such as shared collections, import/export profiles, workspace sync, team templates, or secure desktop storage. However, these features would need to be balanced carefully against the current privacy-first, no-login experience.

The upcoming native desktop applications for macOS and Windows are also worth watching. If implemented well, they could help Aruvix bypass browser memory limits and support truly massive data tasks more comfortably.

API Gateway: The Bouncer Your Microservices Didn’t Know They Needed

Sanu Khan — Wed, 24 Dec 2025 07:45:34 +0000

API Gateway: The Bouncer at the Club Called “Your Backend”

If your system is a party, your microservices are the guests, and your clients are… well… clients.

An API Gateway is the one person at the entrance who checks IDs, controls the crowd, directs people to the right room, and occasionally stops someone from setting the place on fire.

Without a gateway, clients talk to services directly. Which sounds “simple” until you realize you’ve just invited everyone to wander into your kitchen and argue with your fridge.

API Gateway -> Services" width="800" height="533">

What an API Gateway actually does (besides looking important)

An API Gateway is a single entry point for external requests. It sits in front of your services and handles “common chores” so every service doesn’t have to reinvent them badly.

The Greatest Hits (Gateway Edition)

Routing: “/orders goes to Orders Service. Obviously.”
AuthN/AuthZ: “Show me your token. No token? No entry.”
Rate limiting: “You’ve made 10,000 requests in 4 seconds. Please step away.”
Load balancing: “Service instance #3 looks tired. Go to #4.”
Caching: “We already answered this. Here, take the cached response.”
Aggregation: “Client wants one response, backend needs 5 calls. I’ll combine it.”
Protocol translation: “Client speaks REST, service speaks gRPC. I’m bilingual.”

Without a Gateway vs With a Gateway (a short horror story)

Without API Gateway

Clients call multiple services directly:

Client must know every service URL
Every service needs its own auth + rate limit + logging
Changing a service endpoint means client changes (aka “fun”)

With API Gateway

Clients call one endpoint:

One URL to rule them all
Centralized policies (security, throttling, observability)
Backend can evolve without breaking clients (mostly)

Why people love API Gateways (the advantages)

1) Centralized security

You implement authentication/authorization once at the edge—less duplication, fewer inconsistencies, fewer “oops we forgot auth on that endpoint.”

2) Simpler clients

Mobile apps, web apps, third-party clients—everyone hits one gateway instead of juggling service endpoints like a circus act.

3) Better performance knobs

Caching, compression, request shaping, response aggregation—gateways can reduce total calls and smooth backend load.

4) Observability and governance

One place for metrics, logs, tracing correlation, and global policies.

Your monitoring gets less “Where is this failing?” and more “Oh, it’s failing right there.”

5) Versioning and compatibility

You can support /v1 and /v2 without forcing every service to carry legacy baggage forever.

Why API Gateways can still ruin your week (the disadvantages)

Let’s be honest: adding a gateway is adding a new thing to break.

1) It can be a single point of failure

If the gateway goes down, congratulations—you’ve invented distributed downtime.
Solution: run it HA, multi-zone, scalable, and monitored like it’s your paycheck (because it is).

2) Extra latency

It’s another hop. Usually worth it, but it exists.

The fix is good configuration, caching, and not doing “just one more plugin” until it becomes a Christmas tree.

3) Config complexity

Route rules, auth policies, transformations, rate limits, plugins—at scale it becomes a discipline, not a weekend task.

4) Cost and lock-in

Managed gateways cost money. Self-hosted gateways cost engineers (also money). Some solutions can strongly couple you to a cloud ecosystem.

API Gateway vs Load Balancer vs Service Mesh (stop mixing them up)

Load Balancer

Operates at network level (L4/L7 depending)
Distributes traffic, doesn’t usually handle API semantics like auth, quotas, transformations

API Gateway

North–south traffic (clients → services)
API-focused features: auth, rate limiting, versioning, transformation, aggregation

Service Mesh

East–west traffic (service → service)
mTLS, retries, circuit breaking, traffic shaping inside your cluster

They can coexist. In serious systems, they usually do.

Real-world examples (so you can name-drop responsibly)

AWS API Gateway: Common in serverless setups (API Gateway → Lambda).
Kong: Popular in Kubernetes and microservices, plugin-driven, highly extensible.
NGINX: Can be configured as a gateway/reverse proxy with a lot of control.
Traefik: Cloud-native routing with auto-discovery vibes.

Pick based on your environment, governance needs, and how much “platform engineering” you want to own.

When should you use an API Gateway?

Use one when:

You have multiple services and multiple clients
You need centralized security, throttling, and monitoring
You want a stable external API while internals evolve

You might skip it when:

You have a tiny system with one service (for now)
You don’t need cross-cutting policies yet
You’re allergic to operating infrastructure (fair)

A practical mental model (that won’t betray you in interviews)

Think of the API Gateway as:

Front door: one entry point
Bouncer: auth and quotas
Traffic cop: routing and balancing
Translator: protocol and payload shaping
Receptionist: aggregation and consistent error responses

And yes, it also becomes the place everyone blames first. Enjoy.

Quick checklist (what you must design for)

High availability (multi-instance, multi-zone)
Observability (metrics, logs, tracing)
Security controls (auth, mTLS/TLS, WAF integration if needed)
Rate limits / quotas
Deployment strategy (blue/green, canary for config changes)
Clear ownership (someone must maintain it)

Closing thoughts

API Gateways are not magic. They are concentrated responsibility.

Done well, they simplify everything. Done poorly, they become the world’s most expensive bottleneck.

If you’re building microservices: you’re probably going to end up here anyway. Might as well do it on purpose.

Want a follow-up? I can write part 2 on “API Gateway vs API Management” or “Kubernetes: Ingress vs Gateway API vs Service Mesh” with real deployment patterns.

DEV Community: Sanu Khan

52 Possibilities. 5 Cards. No Guessing. Here’s the Algorithm.

The Pigeonhole Principle

Five Cards, Four Suits

Turning 13 Ranks Into Only 6 Possibilities

But How Do We Transmit 1–6?

This Is an Encoding Algorithm

Why This Matters for Software Engineers

Example 1: Hash Tables

Example 2: Database Partitioning and Sharding

Example 3: Scheduling and Resource Allocation

Example 4: Duplicate Detection

Example 5: Distributed Systems

High-Order Computation Isn't Always About More Compute

Think About Search Algorithms

The Information-Theory Perspective

This Pattern Appears Everywhere

A Useful Engineering Question

From Five Cards to System Design

Final Thought

I Built an ERP in 25 Hours With AI — Vibe Coding Is Getting Serious

From requirements to a working system

Codex became an implementation multiplier

Then I attacked the UI

And then came Zaakiy AI

25 hours changed my perspective

Vibe coding doesn't mean "don't understand the code"

AI isn't replacing developers. It's changing developer throughput.

The bottleneck is moving

25 hours. One developer. A lot of AI.

Codex CLI 0.157.0 Broke on Windows — Here’s How I Got Back to Work [DO NOT UPDATE CODEX !! ]

What changed in Codex CLI 0.157.0?

The temporary workaround: --no-daemon

Then I tried the obvious fix: downgrade

The second bug: the standalone installer + Windows PowerShell 5.1

Installing PowerShell 7

Downgrading the standalone Codex CLI to 0.156.1

The complete Windows workaround

If you're on Codex CLI 0.157.0

Option 1 — Temporary workaround

Option 2 — Disable automatic daemon startup

Option 3 — Roll back to 0.156.1

Don't immediately run PowerShell as Administrator

Interestingly, this may not be Windows-only

What I'd like to see improved

1. Daemon startup should fail gracefully

2. The error needs to identify the failing operation

What started as a simple upgrade...

TL;DR

References

Stop Scaling Out: Your Server Might Just Need More RAM

The Scenario

Horizontal Scaling Has a Hidden Invoice

But Vertical Scaling Has a Ceiling

The Better Question

The Architecture I Prefer

Round Robin Is Lying to You: Equal Traffic Equal Load

The Problem Isn't the Algorithm

One Request Is Not One Unit of Work

Servers Aren't Always Equal Either

So We Need Smarter Algorithms?

What Does "Load" Actually Mean?

Round Robin Isn't Bad

The Part Worth Remembering

"What exactly did we balance?"

How to Choose Between SQL, NoSQL, and Everything in Between

Start With the Boring Choice

Relationships Matter

Then the Data Stops Looking So Relational

Think in Access Patterns

Search Is a Different Data Problem

Not Every Relationship Needs a Graph Database

Files Don't Belong Everywhere Either

Now We Have Multiple Databases

Consistency Changes the Decision

CAP Theorem Without the Interview Definition

Build the Decision From Requirements

The Database Architect's Loop

So... SQL or NoSQL?

Don't Choose the Database First

The temporary workaround: `--no-daemon`