DEV Community: Sanu Khan

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.

🦆 DuckDB: The SQLite of Analytics You Didn’t Know You Needed

Sanu Khan — Wed, 20 Aug 2025 06:25:47 +0000

🦆 DuckDB: The SQLite of Analytics You Didn’t Know You Needed

🔥 Why This Matters

Every developer has faced this:

A messy CSV file too big for Excel.
A Pandas dataframe that takes forever to group by.
A dataset that’s too small for BigQuery but too big for comfort.

Enter DuckDB — the SQLite for analytics. It runs inside your app, speaks SQL fluently, and can chew through billions of rows without breaking a sweat.

And here’s the kicker: no server, no setup, no ops.

🛠 What Exactly Is DuckDB?

DuckDB is an open-source, in-process OLAP database designed for analytics.

Think of it like this:

SQLite → OLTP (fast transactions, mobile apps).
DuckDB → OLAP (fast analytics, big aggregations).

Key highlights:

✅ Columnar storage → perfect for crunching numbers.

✅ Vectorized execution → lightning-fast queries.

✅ Embeddable → runs inside your app, notebook, or script.

✅ Zero config → just pip install duckdb and go.

⚡ Why Developers Love It

Faster than Pandas for many data wrangling tasks.
Reads CSV, Parquet, JSON, Arrow — directly.
Works seamlessly with Python, R, or even C++.
Portable, lightweight, and reproducible.

🚀 Real-World Use Cases

1. Data Science Notebooks

Query CSVs and Parquet files with pure SQL. No database servers, no ETL.

import duckdb
duckdb.sql("SELECT category, AVG(price) FROM 'products.parquet' GROUP BY category")

2. ETL Pipelines

Replace slow Pandas joins and filters with DuckDB SQL queries.

3. IoT & Edge Devices

Run analytics on a Raspberry Pi before sending summarized data upstream.

4. App Embedding

Bundle DuckDB into your desktop or mobile app for offline analytics.

5. Rapid BI & ML Prototyping

Test KPIs or prepare ML features locally before pushing to cloud warehouses.

🥊 DuckDB vs The Rest

SQLite → Great for small apps & transactions. Not built for analytics.
Pandas/Polars → In-memory only. DuckDB can handle much bigger data.
BigQuery/Snowflake → Awesome for huge data. But overkill (and $$$) for small to mid datasets.

👉 DuckDB fits the sweet spot: big enough to be powerful, small enough to be simple.

✨ 10 Killer DuckDB Tricks Every Dev Should Know

Query CSV/Parquet without loading

   SELECT * FROM 'data.csv' LIMIT 10;

Query Pandas DataFrames directly

   import pandas as pd, duckdb
   df = pd.read_csv("sales.csv")
   duckdb.sql("SELECT region, SUM(amount) FROM df GROUP BY region")

Output to Parquet

   COPY (SELECT * FROM 'data.csv') TO 'data_out.parquet' (FORMAT PARQUET);

Time-series bucketing

   SELECT time_bucket(INTERVAL '1 hour', timestamp) AS hour, AVG(value)
   FROM 'iot_data.parquet'
   GROUP BY hour;

Join multiple file formats

   SELECT a.id, b.details
   FROM 'customers.csv' a
   JOIN 'orders.parquet' b ON a.id = b.customer_id;

Work with Arrow/Polars seamlessly

Direct conversion with zero copy.
Parallel execution by default

Queries scale with your CPU cores out-of-the-box.
Run in-memory or persistent mode

   PRAGMA database_list;

Export query results back to Pandas

   result = duckdb.sql("SELECT COUNT(*) FROM df").to_df()

SQL + Python mix Combine data wrangling in Pandas with analytics in DuckDB.

✍️ Author Insights

Honestly, DuckDB feels like a cheat code for developers:

I no longer upload every CSV to BigQuery just to run a few queries.
In Jupyter, I can answer 80% of business questions without leaving my notebook.
For teaching SQL to data science juniors, DuckDB is frictionless.

It’s the kind of tool that makes you go: “Where has this been all my life?”

🎯 Recommendations

✅ Use DuckDB when:

You need lightweight analytics inside apps or notebooks.
Your datasets are MBs → 100s of GBs, not petabytes.
You want reproducibility without server dependencies.

❌ Don’t use DuckDB when:

You need concurrent transactions (OLTP apps → use Postgres/SQLite).
You’re working with petabyte-scale warehouses (→ BigQuery/Snowflake).
You require real-time streaming analytics (→ ClickHouse, Druid).

🎯 Conclusion

DuckDB isn’t just another database — it’s a movement toward lightweight, embeddable, analytics-first tools.

If you work with data (and who doesn’t?), you’ll quickly see why it’s called the “SQLite for Analytics.”

Next time you’re stuck between Pandas and BigQuery, remember:

👉 Just Duck It. 🦆

TL;DR

DuckDB = Analytics engine that lives inside your app.
Zero setup, blazing fast, super portable.
Best for: Data science, prototyping, IoT, offline analytics.
Why viral? → It makes data analysis ridiculously simple.

JavaScript Proxy Explained: Powerful Tips for Dynamic Object Handling

Sanu Khan — Mon, 07 Jul 2025 12:42:29 +0000

Learn how to use JavaScript's Proxy object to intercept and control object behaviour. Includes real-world use cases like validation, logging, access control, and reactivity.

JavaScript is full of surprises, and one of the most powerful yet underrated features is the Proxy object. It allows you to intercept, customise, and secure operations on other objects without modifying them directly.

Whether you're building a reactive UI, logging access, or applying security rules, Proxy can be your best friend.

🔍 What is a JavaScript Proxy?

In simple terms, a Proxy wraps an object and allows you to define custom behaviour for fundamental operations like:

Reading (get)
Writing (set)
Deleting (deleteProperty)
Function invocation (apply)
Enumeration (ownKeys)
And more...

💡 Syntax

const proxy = new Proxy(target, handler);

target: The object you want to proxy.
handler: An object that defines "traps" (functions that override default behaviour).

💼 Real-World Use Cases for Proxy in JavaScript

1. 📊 Logging Property Access

Want to know when properties are accessed? A Proxy lets you track this easily.

const user = { name: "Adnan", role: "Admin" };

const loggedUser = new Proxy(user, {
  get(target, prop) {
    console.log(`Property "${prop}" was accessed.`);
    return target[prop];
  }
});

console.log(loggedUser.name); // Logs: Property "name" was accessed.

2. 🛡️ Validating Property Values

Enforce rules when users update object properties.

const settings = {
  volume: 50
};

const validatedSettings = new Proxy(settings, {
  set(target, prop, value) {
    if (prop === "volume" && (value < 0 || value > 100)) {
      throw new Error("Volume must be between 0 and 100");
    }
    target[prop] = value;
    return true;
  }
});

validatedSettings.volume = 80;  // ✅ OK
validatedSettings.volume = 150; // ❌ Error

3. 🔐 Restricting Access to Sensitive Properties

Block access to confidential data like salary or SSN.

const employee = {
  name: "Jane",
  salary: 7000,
  role: "Manager"
};

const secureEmployee = new Proxy(employee, {
  get(target, prop) {
    if (prop === "salary") {
      throw new Error("Access denied to salary");
    }
    return target[prop];
  }
});

console.log(secureEmployee.name);   // ✅ "Jane"
console.log(secureEmployee.salary); // ❌ Error

4. 🔄 Auto-Fallback for Missing Properties

No more checking if a key exists—return defaults automatically.

const defaultConfig = new Proxy({}, {
  get: (target, prop) => prop in target ? target[prop] : "Not set"
});

console.log(defaultConfig.theme); // "Not set"
defaultConfig.theme = "dark";
console.log(defaultConfig.theme); // "dark"

5. 🚫 Making Objects Immutable

Use Proxies to freeze an object’s properties dynamically.

const constants = {
  API_KEY: "12345-SECRET"
};

const immutable = new Proxy(constants, {
  set() {
    throw new Error("Cannot modify constant values!");
  },
  deleteProperty() {
    throw new Error("Cannot delete properties!");
  }
});

immutable.API_KEY = "HACKED"; // ❌ Error

⚙️ Behind the Scenes: How Frameworks Use Proxy

🔄 Vue 3 Reactivity

Vue.js 3 uses Proxy for its reactivity system, replacing the older Object.defineProperty approach used in Vue 2.

import { reactive } from 'vue';

const state = reactive({ count: 0 });
state.count++; // Vue tracks changes via Proxy

✅ Benefits of Using Proxy

🐞 Debugging: Track object usage.
🧼 Validation: Ensure correct data.
🛡 Security: Hide sensitive info.
🧠 Customization: Dynamic behavior.
💡 Fallbacks: Return default values on the fly.

⚠️ Caution When Using Proxy

Can make debugging harder if misused.
Slight performance cost compared to plain objects.
Doesn’t intercept internal slots of built-in types (e.g., Date).

📘 Further Reading

🧵 Final Thoughts

JavaScript Proxies are like magical middlemen—they watch, intercept, and control object behaviour without messing with the original code. Whether you’re developing frameworks, building secure apps, or writing custom logging, Proxies give you superpowers.

Have you used Proxy in production?

💬 Share your use cases in the comments!

🏷️ Tags

#javascript #webdev #frontend #programming #vuejs #codingtips

Creating a Merge Sort Array Prototype for Nested Objects, Strings, and Numbers in JavaScript

Sanu Khan — Wed, 18 Jun 2025 07:01:41 +0000

Learn how to extend JavaScript's Array prototype with a powerful and flexible merge sort function that supports nested objects, strings, and numbers.

🧠 Creating a Merge Sort Array Prototype for Nested Objects, Strings, and Numbers

Sorting arrays is easy — until you need to sort deeply nested objects, ensure stable results, or avoid mutating the original array.

In this post, you’ll learn how to create a powerful, non-mutating mergeSortBy() function on the Array.prototype that supports:

✅ Numbers
✅ Strings (case-insensitive)
✅ Complex nested object keys (e.g., "user.address.city")
✅ Custom comparator functions

🔍 Why Not Just Use `.sort()`?

Feature	`Array.sort()`	`mergeSortBy()` (Custom)
Mutates original array?	✅ Yes	❌ No
Stable sort?	❌ Not guaranteed before ES10	✅ Always
Deep key sorting?	❌ No	✅ Yes
Supports custom comparator?	✅ Yes	✅ Yes

🔄 Step 1: Get Nested Values

function getValue(obj, path) {
  return path.split('.').reduce((acc, key) => acc?.[key], obj);
}

🧮 Step 2: Comparator Helper

function defaultComparator(a, b) {
  if (a == null && b != null) return -1;
  if (a != null && b == null) return 1;
  if (typeof a === 'string' && typeof b === 'string') {
    return a.localeCompare(b);
  }
  return a > b ? 1 : a < b ? -1 : 0;
}

🧩 Step 3: `mergeSortBy` on Array.prototype

if (!Array.prototype.mergeSortBy) {
  Array.prototype.mergeSortBy = function (keyOrFn) {
    const getComparator = () => {
      if (typeof keyOrFn === 'function') return keyOrFn;
      if (typeof keyOrFn === 'string') {
        return (a, b) =>
          defaultComparator(getValue(a, keyOrFn), getValue(b, keyOrFn));
      }
      return defaultComparator;
    };

    const merge = (left, right, comparator) => {
      const result = [];
      let i = 0, j = 0;
      while (i < left.length && j < right.length) {
        result.push(
          comparator(left[i], right[j]) <= 0 ? left[i++] : right[j++]
        );
      }
      return result.concat(left.slice(i), right.slice(j));
    };

    const mergeSort = (arr, comparator) => {
      if (arr.length <= 1) return arr;
      const mid = Math.floor(arr.length / 2);
      const left = mergeSort(arr.slice(0, mid), comparator);
      const right = mergeSort(arr.slice(mid), comparator);
      return merge(left, right, comparator);
    };

    return mergeSort(this.slice(), getComparator()); // non-mutating
  };
}

🧪 Test Cases & Real Examples

✅ 1. Sort numbers

[9, 1, 4, 7].mergeSortBy(); // [1, 4, 7, 9]

✅ 2. Sort strings

["banana", "Apple", "cherry"].mergeSortBy();
// Output: ['Apple', 'banana', 'cherry']

✅ 3. Sort objects with deep keys

const users = [
  { id: 1, profile: { name: "John" } },
  { id: 2, profile: { name: "Alice" } },
  { id: 3, profile: { name: "Bob" } },
];

const sortedUsers = users.mergeSortBy("profile.name");
console.log(sortedUsers.map(u => u.profile.name)); 
// ['Alice', 'Bob', 'John']

✅ 4. Custom comparator

const scores = [
  { name: "A", score: 90 },
  { name: "B", score: 100 },
  { name: "C", score: 95 },
];

const desc = scores.mergeSortBy((a, b) => b.score - a.score);
console.log(desc.map(x => x.score)); // [100, 95, 90]

⏱ Performance Comparison: `.sort()` vs `mergeSortBy()`

const bigArray = Array.from({ length: 100000 }, () => ({
  id: Math.random().toString(36).substring(7),
  value: Math.floor(Math.random() * 100)
}));

console.time("Native sort");
bigArray.slice().sort((a, b) => a.value - b.value);
console.timeEnd("Native sort");

console.time("mergeSortBy");
bigArray.mergeSortBy("value");
console.timeEnd("mergeSortBy");

✅ Stability Test

const people = [
  { name: "Alice", age: 30 },
  { name: "Bob", age: 25 },
  { name: "Charlie", age: 30 },
];

const sorted = people.mergeSortBy("age");
console.log(sorted.map(p => p.name)); 
// ['Bob', 'Alice', 'Charlie'] — Alice before Charlie (same age) ⇒ stable!

🎯 Final Takeaways

You just built a custom merge sort that:

Handles primitives and nested objects
Accepts string paths or comparator functions
Is stable and predictable

⚠️ Performance: Why Native `.sort()` Is Faster Than `mergeSort()`

After testing both Array.prototype.sort() and our custom mergeSort() on complex nested data, the results are clear:

Native Sort: ✅ Faster (~1.3ms)  
Merge Sort: ❌ Slower (~8.5ms)

🚀 Why is Native `.sort()` Faster?

Reason	Description
Engine Optimized	Native `.sort()` is implemented in low-level languages like C++ inside JS engines (e.g., V8).
Hybrid Sorting	Modern engines use Timsort — a hybrid of Merge and Insertion sort — optimized for real-world data.
Better Memory Handling	Avoids frequent array cloning operations like `slice()` and `shift()`, which are costly in JavaScript.
In-place Sorting	Operates directly on the original array without creating new intermediate arrays.
Small-Array Optimization	For short arrays, engines switch to insertion sort, which is extremely fast.

📚 Then Why Bother With `mergeSort()`?

While native sort is faster, writing your own mergeSort() still has value:

✅ Educational: Great way to learn recursion and sorting logic.
🔍 Transparent: Full control over how elements are compared and sorted.
🔄 Immutable Structures: Useful in environments where mutation is discouraged.
📊 Benchmarking: Compare against other algorithms (QuickSort, HeapSort, etc.) for algorithm study.

🧠 Takeaway

Use .sort() in production.

Use mergeSort() to understand how sorting works under the hood.

📬 What Next?

Let me know:

Would you like a TypeScript version?
Should this be a standalone NPM utility?

⭐ Found this helpful? Drop a like, comment, or bookmark!

Why Project Euler Might Be the Most Powerful DSA Trainer You're Not Using Yet

Sanu Khan — Tue, 17 Jun 2025 07:41:04 +0000

“Most coders know LeetCode. Fewer know Project Euler. But those who do? They think deeper, optimise faster, and solve smarter.”

📚 A Tale of Two Coders

Imagine two coders:

Alex solves classic interview-style problems on LeetCode.
Riya prefers tackling math-based programming puzzles on Project Euler.

A few months in, Riya is noticeably better at optimisation, pattern spotting, and problem-solving.

What changed?

👉 She trained with Project Euler.

🧠 What Exactly Is Project Euler?

Project Euler is a collection of 800+ curated problems that blend math, logic, and programming.

Each problem challenges you to:

Spot patterns 🧩
Think algorithmically 🧠
Solve problems without hand-holding 🎯

Unlike most platforms, it doesn’t give you test cases — it gives you a riddle.

🪜 Your 4-Phase Project Euler + DSA Roadmap

🌱 Phase 1: Build Your Foundation (Problems 1–10)

Start with core programming concepts: loops, conditions, and math patterns.

🧩 Example:

Problem 1 – Sum of Multiples of 3 and 5

How many numbers below 1000 are divisible by 3 or 5?

✅ Skills: loops, modulus, arithmetic optimisation

🌿 Phase 2: Master Core DSA (Problems 11–40)

Here, problems require recursion, memoization, and array logic.

🧩 Example:

Problem 14 – Longest Collatz Sequence

Which number under 1 million produces the longest sequence?

✅ Skills: HashMaps, recursion, memoisation

🌳 Phase 3: Think Algorithmically (Problems 41–80)

Time to introduce sieves, prefix sums, and backtracking.

🧩 Example:

Problem 50 – Consecutive Prime Sum

Find the prime below 1 million that can be written as the longest sum of consecutive primes.

✅ Skills: Modular math, optimisation, big number handling

✅ Skills: Prime sieve, sliding window, prefix sum

🌲 Phase 4: Engineer Like a Mathematician (81+)

This level is serious: matrix DP, modular exponentiation, and combinatorics.

🧩 Example:

Problem 97 – Large Non-Mersenne Prime

What are the last 10 digits of a massive prime number expression?

💻 Which Language Should You Use?

Language	Why It’s Good

-------------------------------------------------------------|
| Python | Easy syntax, built-in big integers, math libs |
| C++ | Performance-heavy problems, manual control |
| Java | Strong typing, BigInteger support |
| Haskell | Elegant solutions, great for math-heavy logic |

🏆 Best Choice: Python — it’s perfect for Euler’s math + logic challenges.

🔥 Why Most People Ignore Project Euler (And Why You Shouldn’t)

Common reasons:

“Too mathematical.”
“Not practical for interviews.”

💡 Truth: Project Euler teaches you optimization, reasoning, and how to build your own test cases — skills that ace interviews and improve real-world coding.

Euler makes you solve smarter, not just faster.

🎯 Getting Started (Today!)

Go to projecteuler.net
Create an account.
Start with Problem 1.
Write your code, refactor, and reflect:
- What DSA did you use?
- How did you optimize?
- What patterns did you discover?

✅ Bonus: Post your solutions weekly on GitHub or LinkedIn for habit + portfolio building.

🧩 Final Thoughts

If you want to:

Crack interviews
Think like an algorithm designer
Train for the ICPC/Codeforces level

… then Project Euler is your secret weapon.

Start with 1 problem per day. Let the puzzle teach you.

💬 Let's Talk

What’s the first Euler problem you’ll try?
Want a public leaderboard challenge every weekend?
Interested in a curated “Euler Weekly” newsletter?

Comment below or DM to join a challenge group. Let’s think deeper, together.

How Warp Terminal Saved Me from a Git Disaster (With Just One Prompt)

Sanu Khan — Thu, 08 May 2025 08:50:06 +0000

When Git rebasing goes wrong, Warp Terminal can be your smartest ally. Here's how it helped me reset my branch in seconds.

If you've ever found yourself tangled in a Git mess—conflicts mid-rebase, local changes everywhere, and that sinking feeling of “I’ve broken everything”—you’re not alone. That was me, staring at my screen, mid-panic, until Warp Terminal stepped in like a superhero with a command cape.

I was knee-deep in a rebase gone wrong. My local branch dev/1.0.0-2025 was full of merge conflicts, and the more I tried to fix it, the messier it got. I just wanted to reset everything to match the remote branch. A clean slate.

Normally, this means:

Checking status
Aborting rebase
Fetching from origin
Hard resetting
Cleaning up

…and crossing your fingers that nothing breaks.

⚡ Enter: Warp Terminal

Before I show how Warp rescued me, let me introduce it briefly.

What is Warp?

Warp is a modern terminal built in Rust, designed for the way developers work today. Some standout features:

Blazing fast performance
Blocks-based UI (great for copy/paste and command context)
Autocomplete with inline docs
AI Command Search for natural-language help

It’s like pairing with a senior dev who lives in your terminal.

🧠 Solving Git with One Prompt

Back to the mess I was in.

Instead of fumbling through Git commands, I typed this prompt in Warp:

reset to current remote

And what I got was exactly what I needed:

1. Ensure that there are no important local changes that need to be preserved.
2. Abort the ongoing rebase operation:
   • git rebase --abort
3. Switch to the branch:
   • git checkout dev/1.0.0-2025
4. Fetch all changes:
   • git fetch --all
5. Hard-reset the branch:
   • git reset --hard origin/dev/1.0.0-2025
6. Clean untracked files:
   • git clean -fd
7. Verify everything is synced.

Warp gave me context-aware, clear, and safe steps—tailored to my repo.

🎯 Why It Mattered

In less than a minute, I went from rebase chaos to a clean, synced branch—all without ever leaving my terminal. No copy-pasting from Stack Overflow. No second-guessing syntax. Just one intelligent prompt.

✅ Final Thoughts: Terminal, Reinvented

If you're still using the default terminal your OS shipped with, it's time to level up. Warp Terminal isn’t just for looks—it’s a productivity engine.

It helped me:

Avoid disaster
Save time
Fix my branch painlessly

Next time Git throws you a curveball, let Warp take the wheel.

🔗 Try Warp for free →

✍️ Have you tried Warp? Share your experience in the comments!