DEV Community: Saif Ullah Usmani

Top 10 PDF Tools Everyone Needs

Saif Ullah Usmani — Thu, 23 Apr 2026 20:56:00 +0000

PDFs are everywhere, resumes, contracts, reports, ebooks. But working with them can be frustrating without the right tools.

Instead of installing heavy software, you can handle everything directly in your browser using keynou.com.

Here are the top 10 PDF tools you should be using to save time and simplify your workflow.

📄 1. PDF to Word Converter

::contentReference[oaicite:0]{index=0}

Why you need it:

Turn static PDFs into editable documents.

👉 Use: https://keynou.com/tools/pdf/pdf-to-word

Best for:

Editing contracts
Updating resumes
Extracting content

📑 2. Word to PDF Converter

::contentReference[oaicite:1]{index=1}

Why you need it:

Convert documents into a universal, shareable format.

👉 Use: https://keynou.com/tools/pdf/word-to-pdf

Best for:

Professional sharing
Finalizing documents

🗜️ 3. PDF Compressor

::contentReference[oaicite:2]{index=2}

Why you need it:

Reduce file size without losing quality.

👉 Use: https://keynou.com/tools/compressor/pdf-compressor

Best for:

Email attachments
Upload limits
Faster sharing

🔗 4. PDF Merger

::contentReference[oaicite:3]{index=3}

Why you need it:

Combine multiple PDFs into one file.

👉 Use: https://keynou.com/tools/merger/pdf-merger

Best for:

Reports
Documents bundles
Client deliverables

✂️ 5. PDF Splitter

::contentReference[oaicite:4]{index=4}

Why you need it:

Extract specific pages from a PDF.

👉 Use: https://keynou.com/tools/pdf-splitter

Best for:

Sharing selected pages
Removing unnecessary sections

📊 6. PDF to Excel Converter

::contentReference[oaicite:5]{index=5}

Why you need it:

Turn tables into editable spreadsheets.

👉 Use: https://keynou.com/tools/pdf/pdf-to-excel

Best for:

Data analysis
Financial reports

🖼️ 7. Image to PDF Converter

::contentReference[oaicite:6]{index=6}

Why you need it:

Convert images into organized PDF documents.

👉 Use: https://keynou.com/tools/image/image-to-pdf

Best for:

Scanned documents
Portfolios

📝 8. Text to PDF

::contentReference[oaicite:7]{index=7}

Why you need it:

Quickly create PDFs from raw text.

👉 Use: https://keynou.com/tools/pdf/text-to-pdf

Best for:

Notes
Documentation

🔒 9. PDF Security / Encryption

::contentReference[oaicite:8]{index=8}

Why you need it:

Protect sensitive documents.

👉 Use: https://keynou.com/tools/file-encryptor

Best for:

Confidential files
Client data

🧾 10. PDF Editor

::contentReference[oaicite:9]{index=9}

Why you need it:

Make quick edits without converting.

👉 Use: https://keynou.com/tools/file/document-editor

Best for:

Minor corrections
Quick updates

⚡ Pro Workflow for PDFs

Instead of using tools randomly, follow this:

Convert (if needed)
Edit or extract content
Compress file
Merge or split
Secure before sharing

🚫 Common Mistakes to Avoid

Converting PDFs multiple times (quality loss)
Sending large files without compression
Editing without backup
Ignoring formatting issues after conversion

🧠 Final Thoughts

PDFs don’t have to be difficult.

With the right tools from keynou.com, you can:

edit faster
share easier
work smarter

All without installing anything.

🚀 Start Using These Tools

Explore all PDF tools here:

👉 https://keynou.com/tools

Everything is free, fast, and ready to use.

Getting Started with Online Tools

Saif Ullah Usmani — Tue, 21 Apr 2026 20:55:08 +0000

In today’s fast-paced digital world, productivity isn’t about working more, it’s about working smarter.

Online tools have completely changed how we handle everyday tasks, from converting files to editing media and managing data. Instead of installing heavy software or wasting time on complex workflows, you can now get things done instantly in your browser using keynou.com.

🚀 What Are Online Tools?

Online tools are browser-based utilities that help you perform specific tasks quickly without installing any software.

You simply:

Open the tool
Upload or input your data
Get instant results

👉 Explore all tools: https://keynou.com/tools

⚡ Why Use Online Tools?

1. No Installation Required

Forget downloading large applications. Everything runs directly in your browser.

2. Instant Results

Most tasks take seconds, whether it's compressing an image or converting a file.

3. Free and Accessible

With keynou.com, you get access to powerful tools without subscriptions or hidden costs.

4. Work Anywhere

All you need is an internet connection, your tools are always available.

🧩 Key Categories to Get Started With

📄 File & Document Tools

::contentReference[oaicite:0]{index=0}

Handle everyday document tasks like:

Converting PDFs to Word
Compressing large files
Merging or editing documents

👉 Try:

🖼️ Image Tools

::contentReference[oaicite:1]{index=1}

Perfect for:

Reducing image size
Resizing for social media
Converting formats

👉 Try:

🎬 Video & Audio Tools

::contentReference[oaicite:2]{index=2}

Great for content creators:

Convert video formats
Compress large files
Extract or edit media

👉 Try:

💻 Developer & Data Tools

::contentReference[oaicite:3]{index=3}

Useful for developers and analysts:

Format JSON
Convert CSV to JSON
Encode/decode data

👉 Try:

⚡ Everyday Productivity Tools

::contentReference[oaicite:4]{index=4}

For quick daily tasks:

Generate secure passwords
Create QR codes
Count words or format text

👉 Try:

🧠 How to Use Online Tools Effectively

To get the most out of tools on keynou.com, follow this simple workflow:

Identify your task

(e.g., convert, compress, edit)
Choose the right tool

Go directly to the relevant page
Upload or input data

Keep files clean and organized
Download results instantly

⚠️ Best Practices

Always check output quality after processing
Compress large files before sharing
Use the correct format for your use case
Avoid unnecessary repeated conversions

🔐 Is It Safe?

Yes, online tools on keynou.com are designed with privacy in mind:

Files are processed quickly
No registration required
No unnecessary data storage

🚀 Final Thoughts

Online tools are no longer just a convenience, they are essential for modern workflows.

Whether you're a:

student
developer
content creator
professional

Using the right tools can save you hours of time every week.

👉 Get Started Now

Explore all tools and start simplifying your workflow:

https://keynou.com/tools

No setup. No friction. Just results.

Hostinger 20% off

Saif Ullah Usmani — Wed, 11 Mar 2026 15:10:43 +0000

Launching a website or SaaS? Get 20% off hosting with Hostinger using my link: https://www.hostinger.com?REFERRALCODE=1SAIF931

Fast, affordable hosting with free SSL and easy setup. Perfect for startups, developers, and online businesses.

Django Microservices, A Practical Guide

Saif Ullah Usmani — Sat, 24 Jan 2026 19:46:56 +0000

A Django app is monolith, not a microservice, by default.
A microservice is a separately deployed Django project with its own auth boundary.

Below is the simplest, correct way to do this using JWT shared between two Django services.

Service 1, Auth Service

This is a standalone Django project whose only job is to issue JWTs.

`settings.py`

DJANGO_SECRET_KEY = "same-secret-between-all-microservices"

`auth_service/auth.py`

import jwt
import time
from django.conf import settings

JWT_ALGORITHM = "HS256"
JWT_EXP_SECONDS = 300

def issue_token(user_id: str) -> str:
    payload = {
        "sub": user_id,
        "iat": int(time.time()),
        "exp": int(time.time()) + JWT_EXP_SECONDS,
    }

    token = jwt.encode(
        payload,
        settings.DJANGO_SECRET_KEY,
        algorithm=JWT_ALGORITHM,
    )
    return token

`views.py`

from django.http import JsonResponse
from .auth import issue_token

def login(request):
    user_id = "123"  # assume validated user
    token = issue_token(user_id)
    return JsonResponse({"access_token": token})

This service only issues jwt tokens. When a user sends email and password to login the correct user.

Service 2, Business Service

This is a separate Django project, deployed independently.
Its database doesn't have users or auth related stuff.
It only knows how to read the content of auth service JWT token because of same django_secret_key.

`settings.py`

DJANGO_SECRET_KEY = "same-secret-between-all-microservices"

Custom JWT Middleware

`middleware.py`

import jwt
from django.conf import settings
from django.http import JsonResponse

class JWTAuthMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        auth_header = request.headers.get("Authorization")

        if not auth_header or not auth_header.startswith("Bearer "):
            return JsonResponse({"detail": "Unauthorized"}, status=401)

        token = auth_header.split(" ")[1]

        try:
            payload = jwt.decode(
                token,
                settings.DJANGO_SECRET_KEY,
                algorithms=["HS256"],
            )
        except jwt.ExpiredSignatureError:
            return JsonResponse({"detail": "Token expired"}, status=401)
        except jwt.InvalidTokenError:
            return JsonResponse({"detail": "Invalid token"}, status=401)

        request.user_id = payload["sub"]
        return self.get_response(request)

Register Middleware

`settings.py`

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "your_app.middleware.JWTAuthMiddleware",
]

Protected View in Service 2

from django.http import JsonResponse

def dashboard(request):
    return JsonResponse({
        "message": "Access granted",
        "user_id": request.user_id,
    })

How the services talk

Client calls Auth Service → receives JWT
Client calls Business Service with Authorization: Bearer <token>
Business Service validates token locally
No shared DB, no shared sessions, no Django apps crossing boundaries

That separation is what makes it a microservice. Separate apps, separate databases, linked together based on good old keys.

The important clarification

Multiple Django apps in one project is not microservices
One Django project per service is the minimum bar
Auth must be explicit and stateless
Token validation happens in every service

That is the real line between a Django app and a Django microservice.

React Vs Next

Saif Ullah Usmani — Mon, 19 Jan 2026 06:06:45 +0000

For a long time, I treated React as a hammer.
Every problem looked like a nail.
Dashboards, landing pages, blogs, SEO pages, e-commerce.
Same stack, same patterns, same assumptions.

That worked, until it didn’t.

🧠 The early mistake

In my early production systems, I built everything as a single React SPA. It felt clean and modern. One codebase, one mental model, fast iteration.

Then real traffic showed up.

Marketing pages loaded slowly on mobile.
SEO performance was unpredictable.
Dashboards felt heavy despite being internal tools.
E-commerce pages struggled with crawlability and first paint.

Nothing was “broken” in isolation. The problem was architectural laziness.

⚙️ What production taught me

Dashboards and SEO-sensitive surfaces solve fundamentally different problems.

For dashboards, I care about interaction density, state complexity, and perceived responsiveness after login. React shines here. Client-side state, aggressive caching, optimistic updates, complex charts. SEO is irrelevant, speed after auth is everything.

For landing pages, blogs, and e-commerce, the priorities flip. First contentful paint matters. Crawlability matters. Predictable rendering matters. This is where Next.js earned its place in my stack, not because it is trendy, but because it lets me choose rendering intentionally.

Static generation for programmatic SEO pages.
Server rendering for product and category pages.
Incremental regeneration where content changes slowly but traffic is high.

Same React mental model, different execution strategy.

⚖️ The tradeoffs nobody talks about

This split is not free.

Two deployment pipelines instead of one.
More opinions in the team about where code should live.
Shared components need discipline or they rot fast.
Developers must understand rendering, not just write JSX.

But the alternative is worse.
A single stack that optimizes for everything usually optimizes for nothing.

🔍 Programmatic SEO at scale

The hardest lessons came from programmatic content.

Generating thousands of pages is easy. Making them fast, indexable, and maintainable is not.

I learned to treat content like data. Validate it, cache it, version it. Build guardrails so bad data cannot ship broken pages. Accept that not every page deserves hydration. Sometimes HTML is enough.

That mindset shift mattered more than any framework choice.

📌 What I’d do again, and what I wouldn’t

I would still use React everywhere.
I would not render it the same way everywhere.

I would design around user intent, not developer convenience.
I would explain these tradeoffs early to non-technical stakeholders, especially marketing and leadership, because performance and SEO are business risks, not frontend details.

Closing thought

Senior engineering, to me, is not about knowing more tools. It is about knowing when not to use the same one twice.

When your architecture starts matching user behavior instead of developer preference, everything gets calmer. Teams move faster. Metrics improve. Conversations with leadership become simpler.

That is usually how I know the system is finally growing up.

It works on my localhost 🔥

Saif Ullah Usmani — Thu, 15 Jan 2026 19:52:35 +0000

(Difference between code that works and code that scales)

The most expensive bugs I have shipped were not syntax errors.
They were design decisions that worked perfectly… until they didn’t.
Nothing fails faster than code that was only tested against success.

I learned this the hard way, not from blogs or courses, but from production incidents at 3 a.m. when dashboards went red and users noticed before we did.

🚧 Code that works is easy to celebrate

Early in my career, I was proud of how fast I could ship.

The feature passed tests.
The API responded quickly on my machine.
The demo impressed stakeholders.

And for a while, everything looked fine.

But that code assumed:

Low traffic
Friendly users
Predictable data
One happy path

Reality never respects those assumptions.

📈 Code that scales is built around failure

The first real scaling incident taught me something uncomfortable.

The system didn’t crash because of traffic.
It crashed because of contention, retries, locks, timeouts, and cascading failures I had never designed for.

At scale:

Databases become bottlenecks, not just storage
Network calls fail silently, then loudly
Caches lie
Background jobs pile up
Small inefficiencies compound into outages

Nothing was “wrong” with the code.
It just wasn’t honest about reality.

⚖️ Tradeoffs you only learn in production

Scaling is rarely about perfect architecture. It is about choosing which problems you want to live with.

I have learned to ask different questions now:

Is this synchronous call worth blocking a request?
Is strong consistency actually required here?
What happens if this dependency is slow, not down?
Can we degrade gracefully instead of failing hard?

Sometimes the right answer is slower code with fewer surprises.
Sometimes it is duplication over abstraction.
Sometimes it is accepting eventual consistency to protect availability.

None of those decisions look elegant in isolation.
All of them matter at scale.

🧠 The mindset shift that changed everything

The biggest difference is not technical, it is mental.

Code that works asks:
“Does this solve the problem?”

Code that scales asks:
“What happens when this is stressed, misused, partially broken, or operated by someone new at 2 a.m.?”

That question changes how you log, how you name things, how you design interfaces, and how much you care about operability.

🔚 What I optimize for today

I no longer optimize for cleverness or speed of delivery alone.

I optimize for:

Predictability under load
Clear failure modes
Boring reliability
Systems that are easy to reason about six months later

Scaling is not about writing more complex code.
It is about writing code that tells the truth about the environment it runs in.

That is the difference I wish I understood earlier.

Make one CRM and sell forever 🤑

Saif Ullah Usmani — Tue, 13 Jan 2026 13:01:41 +0000

For years, I did the “right” thing, or so I thought.
Every new client, a new CRM. New repo. New schema tweaks. New logic.
It felt productive. It looked busy. It was a trap.

I didn’t learn this from a blog post.
I learned it from production pain, support calls, and my own burnout.

🚧 The early mistake: building for clients, not for scale

When a client asked for a CRM, I’d build their CRM.

Different flows.
Different permissions.
Different custom fields hard-coded because “this client is special.”

On paper:

Fast initial delivery
Happy client
Clean codebase (for now)

In reality:

5 CRMs → 5 slightly different bugs
Fixing the same issue 5 times
Feature requests that couldn’t be shared
Onboarding a new dev became archaeology

The worst part?
Every “small change” had a multiplied cost.

🧠 The uncomfortable realization

The problem wasn’t programming speed.
It was decision duplication.

No-code tools get praised for “speed,” but what they really optimize is:

One core system, many tenants, infinite configurations.

I was doing the opposite:

Infinite systems, tiny differences, zero leverage.

That’s when it clicked:
Programming isn’t slow. Rebuilding the same product over and over is.

🔄 The pivot: one CRM core, many identities (like inheritance in OOP)

Instead of asking:

“How do I build this CRM for this client?”

I started asking:

“What must never change across CRMs?”

That became the CRM Core:

Users, roles, permissions (policy-driven, not hard-coded)
Pipelines, stages, activities
Contacts, companies, deals
Audit logs, notifications, access rules
Extensible metadata instead of schema forks

Client-specific needs moved to:

Config
Feature flags
Branding
Workflow rules
Tenant-level permissions

Same engine.
Different paint.
Different defaults.

⚖️ Real tradeoffs (not talked about enough)

This wasn’t a magic win.

What got harder:

Initial architecture took longer
Over-engineering temptation was real
“Just for this client” requests needed discipline
Some clients wanted bad ideas — and now I had to say no

What got easier (and compound):

Bug fixes once, everywhere
New features became revenue, not cost
Onboarding a client dropped from weeks to days
Support became pattern-based, not detective work
Rebranding was a config change, not a rewrite

🔧 Lessons I learned the hard way

❌ Custom code feels fast until version 3
❌ DRY across repos is still duplication
✅ Multi-tenancy is a business decision, not just a technical one
✅ Config > conditionals
✅ Saying “no” to one client can say “yes” to ten future ones
✅ No-code tools don’t beat engineers — systems thinking does

🧩 The maturity shift

Junior me optimized for delivery.
Mid-level me optimized for code quality.
Senior me optimizes for leverage.

Leverage in:

Architecture
Maintenance cost
Team sanity
Business scalability

Once you feel the difference, you can’t unsee it.

Closing thought

If you’re rebuilding the same product again and again, you’re not moving fast, you’re running in circles.

Build a core.
Protect it.
Let everything else be replaceable.

That’s not over-engineering.
That’s respect for your future self.

EC2 (single instance with db and redis and all) vs EC2 + RDS + MemoryDB, ECS/EKS (docker-based approach): when and why

Saif Ullah Usmani — Sun, 11 Jan 2026 22:42:16 +0000

Early in my career, I thought architecture was about picking the right stack.
Years later, after a few outages, 3 a.m. rollbacks, and uncomfortable postmortems, I learned it’s really about picking the right compromise for where you are right now.

I’ve run production systems on a single EC2 box with everything installed.
I’ve also migrated those same systems, sometimes painfully, into RDS, MemoryDB, ECS, and later EKS.

Both worked.
Both failed.
Here’s what experience taught me.

🧱 Phase 1: The “Everything on One EC2” Reality

Yes, I’ve done it.
App server, PostgreSQL/MySQL, Redis, background workers, all on one EC2 instance.

Why it made sense at the time:

One bill, one server, one mental model
No network latency between app, DB, and cache
Fastest way to ship when the team is small
Debugging was… oddly comforting (SSH into one box)

What broke first in production:

Disk I/O contention during peak writes
Memory pressure: Redis vs DB vs app fighting silently
“Just restart the instance” becoming a risky decision
Backups and upgrades turning into manual rituals

The biggest issue wasn’t uptime.
It was blast radius.
Every change felt dangerous because everything shared the same failure domain.

🔁 Phase 2: EC2 + RDS + MemoryDB (Decoupling Painfully, But Intentionally)

Moving the database and cache out felt expensive at first.
It was more expensive. But it was also the turning point.

What improved immediately:

Predictable performance (especially under load)
Clear ownership of resources
Backups and failover stopped being “someone’s script”
App deploys no longer risked data integrity

The tradeoffs people don’t talk about:

Network latency is real and measurable
Misconfigured security groups can take you down faster than bad code
You lose the illusion of simplicity, now you need observability

But here’s the thing:
Once traffic, data, or business expectations grow, managed services buy you time and safety, not just convenience.

This is usually where teams should be, even if they resist it.

📦 Phase 3: ECS / EKS (Containers Don’t Fix Architecture)

Containers didn’t solve my scaling problems.
They solved my operational discipline problems.

Why Docker + ECS/EKS started making sense:

Multiple environments stopped drifting
Rollbacks became boring (a good thing)
Horizontal scaling stopped being theoretical
Teams could work in parallel without stepping on each other

What I underestimated early on:

Kubernetes adds cognitive load before it adds value
Bad architecture in containers is still bad architecture
You need maturity in monitoring, logging, and alerts first

ECS worked well when the team wanted guardrails.
EKS made sense only when the organization had strong platform ownership.

Containers are a multiplier.
They multiply clarity or chaos.

⚖️ What Experience Taught Me (The Non-Obvious Lessons)

Single EC2 is not “wrong”, it’s often the most honest starting point
Managed services trade money for sleep
Decoupling is about failure isolation, not fashion
Orchestration should follow discipline, not precede it
The costliest system is the one your team can’t reason about at 2 a.m.

Architecture maturity is less about scale and more about operational confidence.

🧠 The Real Question I Ask Now

Not “Is this scalable?”
But:

“What will break first, and how hard will it be to recover?”

That answer not hype, not trends should drive your choice.

If there’s one thing years in production taught me, it’s this:
Good architecture grows with the team, not ahead of it.

ReactJs can kill you in production

Saif Ullah Usmani — Sun, 11 Jan 2026 13:05:00 +0000

Latency creeps in, bugs multiply, teams lose confidence, and “small changes” start taking days instead of hours.

This isn’t about React being bad.
It’s about how poor React decisions compound over time.

🚧 What actually went wrong in production
Early on, the app felt fast. Features shipped quickly. Everyone was happy.
Then scale arrived.
User count grew
API traffic spiked
UI complexity increased
Multiple engineers touched the same code paths
That’s when cracks turned into outages.
Not because of one big mistake, but because of many small, ignored ones.

🔁 Re-rendering without discipline
Components re-rendering on every keystroke
Props changing shape every render
On lower-end devices and real networks? Painful.

Lesson: Rendering is not free. React makes it easy to re-render, not cheap.

⏱️ No debouncing, no throttling, no mercy
Search inputs hitting APIs on every keypress.
Scroll events firing dozens of times per second.
The backend started looking like the problem.
It wasn’t.

Lesson: Frontend inefficiency scales faster than backend cost.

🧠 State management without a strategy
No single mental model.

Bug fixes required tracing state across five layers of components.
Lesson: State chaos doesn’t show up in demos — it shows up during incidents.

🌗 No theming, no single source of truth
Hardcoded colors. Inline styles. Repeated constants.
When branding changes came in, it turned into a multi-day refactor.

Lesson: If a value appears in more than one place, it’s already a liability.

🔌 API calls scattered everywhere
Every component knew how to talk to the backend.
Different error handling. Different retries. Different headers.
When auth logic changed, the blast radius was massive.

Lesson: No single point of change means every change is risky.

🧱 File structure that doesn’t scale
Flat folders. No boundaries. No ownership.
New engineers took weeks to become productive.
Senior engineers became bottlenecks.
Lesson: File structure is an architecture decision, not a formatting preference.

📦 No code splitting, no lazy loading
The initial bundle kept growing.
Users felt it before metrics did.
Lesson: Performance debt compounds invisibly, until users leave.

🧩 The real mistake
Lack of planning for scale, assuming React would “handle it” later.
React gives you enough rope to hang your product if you’re careless.

🧠 What I do differently now
Treat rendering cost as a first-class concern
Design state flow before writing components
Centralize API interaction aggressively
Plan file structure for future teams, not current comfort
Optimize for change, not just delivery speed
This isn’t over-engineering.
It’s respect for production.

Final thought
Most frontend failures are labeled as “performance issues” or “React problems.”
In reality, they’re engineering maturity problems.

Elasticsearch - How I failed when I needed fast searching

Saif Ullah Usmani — Sat, 10 Jan 2026 11:26:00 +0000

For a long time, I thought Elasticsearch was the obvious answer.
It was fast. It scaled. Everyone I respected was using it.
So when our system started to feel slow, I added Elasticsearch without hesitation.

That decision worked… until it didn’t.
🚧 The problem I was actually solving
In production, our pain wasn’t search speed.
It was real-time correctness.

We had workflows where:
A user action needed to be reflected immediately
State changes had to be visible within milliseconds
“Eventually consistent” was not good enough to explain to customers or support teams

But at the time, I framed the problem incorrectly:
“Queries are slow → add Elasticsearch”

That framing cost us months.

🔍 What went wrong at scale
Elasticsearch did exactly what it promises:
fast, distributed search over indexed data.

What it does not promise:
Strong real-time guarantees
Immediate consistency after writes
Acting as a primary data source for transactional flows

In real production traffic, we started seeing:
Recently updated records missing from results
Edge cases where writes succeeded but reads lagged
Complex retry and refresh logic creeping into application code

Every bug was “rare”.
Together, they were constant.

Non-technical stakeholders didn’t care why it happened.
They just saw data that felt unreliable.

⚖️ The tradeoff I underestimated
Elasticsearch trades correctness now for performance at scale.

We needed:
Predictable reads after writes

🧠 The lesson that stuck with me
The mistake wasn’t using Elasticsearch.
The mistake was using it to compensate for a poorly defined problem.
Fast search ≠ real-time data retrieval
Indexing ≠ state management
Scalability ≠ correctness
Once we re-centered the architecture around:
A primary, strongly consistent data store
Clear read/write paths
Search used only where search made sense
The system became calmer.
Incidents dropped.
Engineers slept better.
🌱 How this changed how I design systems
Today, I’m much slower to introduce “powerful” infrastructure.
Before adding anything new, I ask:
What guarantee does this system give me?
What guarantee does it explicitly not give?
What failure will I be debugging six months from now?
Most production pain doesn’t come from lack of tools.
It comes from misaligned guarantees.
Closing thought
Elasticsearch is an excellent tool.
It just wasn’t the right one for a problem that required trust, not speed.
Experience has taught me this:
Architectural maturity isn’t about knowing more technologies — it’s about knowing when not to use them.
That lesson only comes from shipping, breaking things, and owning the consequences.

SeniorSoftwareEngineer

StaffEngineer

EngineeringLeadership

TechnicalDecisionMaking

SystemOwnership

BackendEngineering

SystemDesign

ScalableSystems

DistributedSystems

ProductionExperience

Redis overdose

Saif Ullah Usmani — Fri, 09 Jan 2026 11:25:49 +0000

For a long time, Redis felt like a silver bullet.
Need speed? Redis.
Need caching? Redis.
Need queues, rate-limiting, sessions, feature flags? Redis everywhere.

I’ve personally made that mistake and paid for it later at scale.

In the beginning, Redis is amazing:
Sub-millisecond reads
Simple data structures
Easy to deploy
Easy to justify

We started caching everything:
Auth sessions
API responses
Database query results
Counters
Background job states
Even business logic flags
Performance skyrocketed.
The mistake wasn’t using Redis.

The mistake was making Redis a core dependency for everything.

💥 What Broke at Scale
As traffic grew, Redis slowly turned from a helper into a single point of failure.

Here’s what started happening:
1️⃣ Redis Became Our “Second Database”
Instead of being a cache, Redis became stateful infrastructure:
Critical data existed only in Redis
Expiration bugs caused silent data loss
Cold restarts created cascading failures
At that point, Redis outages weren’t “performance issues” they were production incidents.

2️⃣ Latency Looked Great, Until Throughput Collapsed
This is something many teams miss:
Low latency ≠ High throughput
Redis can respond in microseconds, but:
Single-threaded command execution
Blocking commands (KEYS, large LRANGE, big Lua scripts)
Huge keyspaces with poor eviction policies

At scale:
P99 latency exploded
CPU maxed out
Network bandwidth became the bottleneck
Timeouts started propagating to APIs
Redis didn’t slow down — everything around it did.

3️⃣ We Used Redis Where the Database Was Better
Some data:
Needed strong consistency
Needed transactions
Needed relational integrity

But Redis was faster, so we used it anyway.
That led to:
Data mismatch between DB and cache
Complex cache invalidation logic
Hard-to-debug race conditions

At some point, the “performance optimization” was costing more engineering time than it saved.

🧯 The Turning Point: Redis Is a Tool, Not a Crutch
The real lesson wasn’t “Redis is bad”.
The lesson was:
Redis must be intentionally limited in responsibility.

We redefined Redis as:
A performance layer
Not a source of truth
Not a workflow engine
Not a business logic store
That mindset shift changed everything.

☁️ Hosting Redis Properly on AWS: MemoryDB vs Self-Managed
After multiple painful incidents, we moved away from self-managed Redis.

Why AWS MemoryDB?
Key reasons:
Multi-AZ with transactional durability
Redis-compatible but designed for high availability
Faster failover
No manual replication hell

Yes, it costs more.
But outages cost far more.

⚖️ Latency vs Throughput: The Tradeoff That Matters
This is the part most blogs skip.
Latency
Redis excels at single-key reads
Network placement matters more than instance size

Throughput
Sharding is mandatory at scale
Bigger instances ≠ linear throughput
Avoid large payloads

Rule I live by now:
If Redis needs vertical scaling, the design is already wrong.

EC2 and Django - Restart kills the server

Saif Ullah Usmani — Fri, 09 Jan 2026 11:10:04 +0000

For a long time, my backend looked healthy.

CPU wasn’t maxed. Memory wasn’t fully used.

Yet users were getting slow responses… and deployments felt risky.

That was my first real lesson:

Infrastructure can fail you quietly before it fails loudly.

🚧 The setup that worked… until it didn’t

I was hosting a production Django app on a single EC2 instance, running behind Gunicorn.

On paper, the instance had enough RAM and decent specs.

In reality, the application never came close to using what I was paying for.

Why?

Because Gunicorn doesn’t automatically scale with your instance.

It only uses what you explicitly allow it to use.

I had:

One Gunicorn service

A small number of workers

One port

No real load balancing

Restart-based deployments

It worked fine for early traffic.

At scale, it became a bottleneck disguised as stability.

🧠 The hidden constraint: workers and memory

Here’s the part many teams learn the hard way:

Each Gunicorn worker is a separate process

Each process has its own memory ceiling

If you under-provision workers, your app can’t consume available RAM

If you over-provision blindly, you’ll trigger OOM kills

So even though EC2 showed free memory, my app couldn’t use it.

The fix wasn’t “bigger EC2”.

The fix was intentional worker strategy.

I learned to:

Size workers based on RAM, not guesses

Understand sync vs async workers

Treat Gunicorn config as capacity planning, not boilerplate

⚙️ Why gevent changed the game for I/O-heavy traffic

A big part of our load wasn’t CPU-heavy.

It was:

API calls

DB waits

Network I/O

External services

Classic sync workers were wasting time waiting.

Switching to gevent wasn’t about “multithreading hype”.

It was about concurrency efficiency.

With gevent:

One worker could handle many concurrent requests

Memory usage became more predictable

Latency improved without throwing more hardware at the problem

Not a silver bullet, but the right tool for the workload.

🔁 Zero-downtime updates: ports > restarts

The moment traffic grows, this becomes non-negotiable.

Restarting Gunicorn to deploy meant:

Dropped connections

Failed requests

Nervous releases

So I moved to:

Running multiple Gunicorn instances on different ports

Using Nginx as a reverse proxy

Gradually shifting traffic between ports during deploys

This gave me:

Zero-downtime updates

Rollbacks without panic

Confidence during releases

It wasn’t fancy.

It was operational maturity.

⚖️ Tradeoffs I had to accept

This setup isn’t “free”:

More ports = more ops discipline

Worker tuning requires monitoring, not guesses

gevent needs code that plays nicely with async I/O

You must understand your traffic patterns

But the upside?

Full utilization of EC2 specs

Predictable scaling

Fewer production surprises

Cleaner upgrade paths later (ECS, Kubernetes, etc.)

📌 What this experience taught me

Scaling is not about adding resources, it’s about unlocking the ones you already have

Defaults are for demos, not production

Memory, workers, and concurrency are architectural decisions

Stability comes from understanding, not tooling

Most importantly:

Senior engineering isn’t about knowing more tools.

It’s about knowing why things break quietly.

If you’re running production workloads and things feel “fine but fragile”,

look closely the ceiling might already be there.

#SeniorSoftwareEngineer #BackendEngineering #Django #PythonEngineering

#CloudArchitecture #AWS #ProductionSystems #ScalableSystems

#EngineeringLeadership #HiringEngineers