DEV Community: Ez Eldeen Mushtaha - @ezmu

🌙 Why I Built MidKnight

Ez Eldeen Mushtaha - @ezmu — Sun, 12 Jul 2026 19:15:51 +0000

💭 Before We Start

This isn't a technical article. It's not an explanation of algorithms, nor a showcase of my programming abilities. This is a conversation between two people who are suffering from the same thing.

I'm not here to tell you I'm smarter than you, or that my language is better than yours, or that my framework surpasses yours. I'm here because I'm tired, and I think you're tired too.

😩 The Confession

You know what really bothers me?

That I have a machine capable of doing the impossible—theoretically.

Yet, when I want to run a simple web application—something that does what websites did twenty years ago—the machine stops. It breathes heavily. It complains.

Why?

Because I told it to pass through seven layers of software before reaching anything useful. Because I loaded it with two frameworks, four databases, twelve libraries, twenty-seven extensions, and fifty-three configuration files.

Because the industry convinced us this is evolution. That bloat is maturity. That adding another layer is the solution.

And we all bought it.

🔄 The Shift

At some point, I got tired. Not of programming—I'll never stop programming. But of the feeling that I'm doing extra work, using extra resources, adding extra complexity, just to achieve what my programming ancestors did with less than a tenth of what I have.

Because I've lived through the evolution of software, development environments, and hardware over 20 years. I've seen everything with my own eyes. I can't claim ignorance.

So, I started asking a different question.

Not: "What's the best library for this?"

But: "Do I need a library at all?"

Not: "What's the fastest framework?"

But: "Do I need a framework?"

And the answer, most of the time, was no.

🏗️ What I Learned

That the biggest obstacle to efficient software isn't the processor, memory, or disk.

It's the complexity we add ourselves.

Every library we add is a potential point of failure. Every framework we adopt is an extra layer between us and the machine. Every dependency we add is something else that can conflict, break, or slow performance.

And we've reached a point where solving the problem is more complex than the problem itself.

⚡ What I Did

I decided to build something different.

Not better. Not stronger. Just different.

Something that depends on nothing. Something that asks no one for permission. Something that stands at the gate, deciding whether a request is worth waking your entire application for, and if not, handles it itself.

80 kilobytes of compiled C code. No dependency hell, no node_modules, no composer.lock.

Something that protects your app from attacks, caches what's static, and searches through data—all without asking you to install two frameworks, a database, and a monitoring tool.

😌 What I Felt

When I saw it work for the first time, I didn't feel pride. I felt relief.

Relief that there's another way. That we're not forced to continue in this spiral of bloat. That the machine I bought twelve years ago is still capable of amazing things, if I stop telling it that it's helpless.

📊 The Real Numbers

Because I know some people need numbers:

Metric	Value
Requests per second	6,892
Success rate	100%
Data transfer	321 MB/s
Binary size	80 KB
Dependencies	0
Device age	12 years

These numbers aren't for boasting. They're just to confirm what we all feel: that hardware isn't the problem.

🗣️ Why I'm Telling You This

I'm not here to convince you to use what I built.

I'm here to say: You're not crazy.

If you feel things have become more complex than they should be, you're right.

If you feel you spend more time managing dependencies, resolving conflicts, and updating packages than writing actual code, you're not alone.

If you've added Redis, added Elasticsearch, used a CDN, implemented multiple caching mechanisms, changed databases, and your system still crashes at the first 100 concurrent requests—know that the problem isn't in your tools.

The problem is in the structure itself.

You're building on a shaky foundation, then you're surprised when the building collapses.

You've done what you had to do. You followed best practices. You used the recommended tools. But from the start, the structure was wrong.

And your systems still crash.

💡 The Philosophy

What We Do Differently:

Aspect	Traditional	MidKnight
Dependencies	Hundreds of packages	0 dependencies
Size	Megabytes	80 kilobytes
Language	Interpreted/Managed	C (Compiled)
Model	Request → App → Database	Request → Smart Proxy → (Cache or App)
Memory	Repeated copying	Zero-Copy
Concurrency	Separate processes	Lightweight threads

What We Don't Do:

❌ We don't depend on Node.js, Python, or PHP
❌ We don't depend on Nginx, Apache, or Varnish
❌ We don't depend on Redis, Memcached, or Elasticsearch
❌ We don't use Java, Go, or Rust

(we work in front of them)

We build from scratch. No middlemen. No dependencies.

┌─────────────────────────────────────────────────────────────────────────────┐
│                         COMPLETE DATA FLOW                                 │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  Client Request                                                             │
│       ↓                                                                     │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │                     MIDKNIGHT GATEKEEPER                           │   │
│  │  1. 🛡️ DDoS Check                                         │   │
│  │  2. 💾 Cache Lookup                                 │   │
│  │  3. 🧠 Logic Engine                                      │   │
│  │  4. 🔍 Full-Text Search  if needed                        │   │
│  │  5. 🔗 Graph Query  if needed                             │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│       ↓                                                                     │
│       ├── 💾 CACHE HIT → Response (0.1ms)                                  │
│       │                                                                     │
│       └── 📦 CACHE MISS → Backend (50-200ms)                               │
│                              ↓                                              │
│                      ┌─────────────────────┐                               │
│                      │   YOUR APPLICATION   │                               │
│                      │   (Laravel, etc)     │                               │
│                      └─────────────────────┘                               │
│                              ↓                                              │
│                         📦 Response                                         │
│                              ↓                                              │
│                      💾 Store in Cache                                      │
│                              ↓                                              │
│                      ⚡ Response (0.1ms next time)                          │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

🌙 MidKnight

The knight that stands at the gate. Not just a tool that stores data, but a guardian that protects your application, quietly, efficiently, without noise. It watches every request before it touches your app, doesn't allow attacks to pass, and doesn't allow repeated requests to wake your app unnecessarily.

MidKnight is not just a server. It's a statement.

A statement that software can be fast without being bloated, powerful without being complex, efficient without being fragile.

📬 If You're Interested

LinkedIn: Wael

Note: MidKnight is currently in Beta. We're working on stabilizing the final features and improving performance. The licensing model and official release details will be announced soon. Stay tuned for updates.

My LinkedIn: EZ-Eldeen

#MidKnight #Software #Simplicity #Performance #Development

The Performance Illusion

Ez Eldeen Mushtaha - @ezmu — Mon, 06 Jul 2026 11:45:30 +0000

Why Web Systems Collapse Under Real Load — and Why We Keep Believing the Benchmarks

“In the lab, PHP served 12 million operations per second. In production, it barely reaches 500 requests per second.”

This is not an exaggeration. It is the difference between the controlled environment and the real world.

Every week, we are fed magical numbers: “Redis does 100,000 ops/sec”, “Node.js handles thousands of concurrent connections”, “Laravel is fast and secure.”

But when real users arrive, when network latency kicks in, when threads start fighting for resources — those numbers evaporate like a bad dream.

The question is not “which language is fastest?”

The real question is: “Why do we spend 90% of CPU time on preparation, and only 10% on execution?”

I. The Bootstrapping Tax

Rebuilding the house for every visitor

Imagine owning a house. Every time a visitor arrives, you demolish the entire building, reconstruct it from scratch, and then open the door. After they leave, you demolish it again.

This is exactly what modern frameworks do on every single request.

Laravel / Rails — loads 50+ Service Providers, builds a DI container, registers routes, initialises connections.
Spring Boot — loads context, scans annotations, builds beans, initialises data sources.
Django — loads apps, initialises middleware, builds the ORM, prepares templates.

The result: 70–90% of CPU time is spent on preparation, not on execution.

“Why do we design a system that consumes 90% of its resources on preparation and only 10% on execution?”

II. Threads — The Silent Killer

The thread that doesn’t work, but waits

If Bootstrapping is the wound, then Threads are what make that wound bleed to death.

Under load, threads are held hostage: they wait for I/O, they wait for locks, they wait for connection pools — they spend most of their life doing nothing.

Nginx/Apache — assigns a thread/process per request. Under high load, the thread pool exhausts, requests pile up.
PHP-FPM — fixed number of children. When requests arrive faster than children can process, they queue and then get refused.
Laravel Bootstrapping — happens inside the thread, preventing it from handling other requests.
Redis (Network I/O) — the thread blocks, waiting for Redis. Blocking I/O is the executioner.

The result: a slow, painful cascade of accumulation, contention, and collapse.

The deadly embrace: Threads + Connection Pools

Imagine: 10 Redis connections, 50 PHP-FPM children, and 100 concurrent requests.

40 children grab the 10 connections and wait for Redis.
10 children wait for a free connection (blocking).
New requests pile up in the queue.
The system enters a deadlock spiral.

“Threads are not bad. But we use them badly. We make them wait instead of work.”

III. Protocol Overhead

When protocols become the enemy of performance

HTTP was designed in the 1990s to serve HTML pages. Today we use it for JSON, WebSockets, streaming, and real-time data. Each layer we add, we pay for:

TCP Handshake — 1–3 ms (or more on slow networks)
TLS Handshake — 2–5 ms (HTTPS)
HTTP Headers — 0.5–2 ms
Request Parsing — 0.5–1 ms
Response Serialization — 1–3 ms

The Stateless trap

In the web, every request is a fresh start. No shared context between requests — even from the same user. This makes scaling easy, but performance abysmal.

“We re-introduce the user to the system 100 times per session, as if we’ve never met them before.”

IV. Why Current Solutions Fail

1. Serverless — shifting cost, not solving it

Serverless does not reduce bootstrapping. It hides it behind a “pay-per-use” curtain. And on cold starts, the nightmare returns — often worse, with added latency of several seconds.

2. Microservices — network hell

Instead of one codebase, you now have 20 services communicating over the network. Each request becomes a chain of network calls.

Auth service → network call
Users service → network call
Orders service → network call
Notifications service → network call

Result: total latency = sum of all network RTTs. Threads wait across services, multiplying the deadlock risk.

3. Persistent systems (RoadRunner, Swoole) — memory nightmares

They solve bootstrapping, but introduce memory management hell:

Memory leaks accumulate fatally.
Code reload needs careful orchestration.
State management across threads requires locks, increasing contention.

“Microservices are not a solution to performance. They are a transfer of the problem from one codebase to an entire network.”

V. The Performance Decay Graph

Before we look at the numbers, picture this:

        OPERATIONS PER SECOND
        ──────────────────────►
  10M  │  ████  (Raw Sockets)
       │  ████
   1M  │  ███   (+PHP)
       │  ███
 100K  │  ██    (+HTTP)
       │  ██
  10K  │  █     (+PHP-FPM)
       │  █
   1K  │  ░     (+Laravel Boot)
       │  ░
  500  │  ░     (+Redis/ORM)
       └─────────────────────►
        C1   C2   C3   C4   C5

Each step to the right is a new layer of “convenience”.

Each step upward is lost performance.

This is the graveyard of modern web engineering.

Latency per Layer (ms)

Layer	Latency (ms)
0. Raw Sockets (C)	0.0001
1. + PHP (Sockets)	0.1
2. + HTTP (Nginx)	1.0
3. + PHP-FPM	5.0
4. + Laravel Boot	20.0
5. + Redis (Network)	25.0
6. + Eloquent (ORM)	50.0

Thread Multiplication Factor (real vs theoretical)

Layer	Threads (real)
0. Raw Sockets (C)	1
1. + PHP (Sockets)	3
2. + HTTP (Nginx)	12
3. + PHP-FPM	48
4. + Laravel Boot	192
5. + Redis (Network)	384
6. + Eloquent (ORM)	768

Throughput Collapse (requests/sec)

Layer	Throughput (req/s)
0. Raw Sockets (C)	10,000,000
1. + PHP (Sockets)	200,000
2. + HTTP (Nginx)	50,000
3. + PHP-FPM	10,000
4. + Laravel Boot	2,000
5. + Redis (Network)	1,500
6. + Eloquent (ORM)	500

Interpretation: From 10 million ops/sec at the bare metal down to ~500 requests/sec with Laravel + ORM + Redis.

Each layer adds latency, consumes threads, and collapses throughput.

VI. Towards a New Engineering — Principles Only

All current solutions try to improve the existing stack. But the stack itself is the problem.

Core principles for a different path

Minimise Bootstrapping — load code and resources once. Reuse context across requests.
Eliminate Blocking I/O — prefer non-blocking I/O. Reduce network dependency for data access.
Manage threads intelligently — reduce contention. Use atomic operations over locks.
Data Locality — bring compute to data, not data to compute. Zero-copy where possible.
Stateless for scale — but be aware of the trade-offs.

“The solution is not to make the language faster. It is to change how we access data. Not to improve tools, but to redesign the system.”

Conclusion: The Coming Battle

“If bootstrapping is the number one enemy of performance, why do we still rebuild the house for every visitor?”

We stand at a crossroads:

Path one: Keep buying more servers to compensate for bloated code.
Path two: Redesign the way we access data.

The coming battle is not between programming languages. It is between deliberate engineering and blind assembly.

“We buy servers with 32 cores and 64 GB RAM, yet we use them as if they were machines from the 1990s. Not because the CPU is slow, but because we make threads wait. We wait for bootstrapping. We wait for the network. We wait for connections. The thread does not work. It waits. And in the world of the web, waiting is death.”

Principles alone are not enough to build a system. But they are enough to change how you think.

About the author

Ez Eldeen A. Mushtaha deconstructs dogmatic models, cosmological dogmas, and messy code. He believes that real engineering begins when you stop believing marketed numbers and start measuring reality.

When Did We Stop Laughing at Java? (And Why We Should Be Crying Instead)

Ez Eldeen Mushtaha - @ezmu — Sun, 31 May 2026 20:07:57 +0000

Back in 2006, the tech world had a favorite punching bag: Java.

We joked about its sluggishness, its memory-hungry JVM, and its "Write Once, Run Anywhere" slogan that felt more like "Write Once, Debug Everywhere." Java wasn’t a joke because it was bad—it was a joke because it was a "Black Box." It was a massive, opaque monolith that ate RAM for breakfast and left developers guessing what was happening under the hood.

So, what happened?

Sun Microsystems did the unthinkable: they tore down the temple. They opened the source, invited the world to look inside, and turned a "Black Box" into an engineering laboratory. The algorithms were laid bare, the memory leaks were exposed, and the community—instead of just laughing—started fixing. The "joke" died because transparency made it impossible to hide incompetence.

But here is the dark irony of 2026:

We stopped laughing at Java, but we’ve built something far worse. We have replaced the "Java Monolith" with a "Dependency Hell" of our own making.

Today, we aren't building software; we are building fragile towers of dependencies held together by "hope" and "server-side-caching."

People ask me why I still touch C and C++. It’s simple: I enjoy the silence of a system that does exactly what I tell it to do, without needing a "wrapper," a "middleware," or a "dependency-injection-container-manager-pro-max" to decide which variable goes where.

We have fallen in love with "Layering." We mask our inability to manage hardware resources by adding three more layers of abstraction. We call it "Scalable Architecture," but in reality, it’s just an expensive way to burn CPU cycles on useless boilerplate code. We have created a new generation of "Black Boxes"—only this time, they aren't even optimized. They are just bloated.

The Solution?

It is time to stop the madness.

Back to Basics: Software is meant to run on hardware, not "float" on top of a mess of third-party dependencies.

If we want to stop being the punchline of the next decade's tech jokes, we need to stop treating our systems like magic.

Stop layering. Fix your engines.

Measure First: If your code is slow, stop adding layers. Find the bottleneck. If you don't know where it is, you aren't an engineer; you're just a gambler. If you are looking for a deep dive into the philosophy of modern software development and the "Circles" we currently find ourselves trapped in, I have detailed this in my manifesto, A Programmer’s Inferno.

Tear Down the Temple: Open your own code. If you can't explain how a function interacts with the memory, you shouldn't be using that framework in a production environment.
For those working within the PHP ecosystem, I have compiled my architectural notes and performance strategies in The Performance Bible for Laravel.

Stop Blaming PHP: Introducing The Performance Bible for Laravel

Ez Eldeen Mushtaha - @ezmu — Mon, 25 May 2026 21:39:40 +0000

"PHP is slow."
"Laravel can't scale."

We hear these tired arguments every day. Developers love blaming the tool—the "car"—instead of the design—the "road."

It’s easy to throw more RAM at a server, but adding more hardware is often just a tax you pay for inefficient code and poor architectural decisions.

After years of architecting high-scale systems, I realized that many Laravel developers are missing a foundational understanding of why certain practices are slow. This led me to open-source The Performance Bible for Laravel, a comprehensive 30-topic guide designed to take you from writing basic code to engineering resilient, high-performance systems.

The Philosophical Foundation: Mathematics Always Beats Physics

Before we optimized a single line of Laravel code, we established a core principle in Volume I: Philosophical Foundations:

The ultimate bottleneck is rarely the programming language itself; it’s the algorithm complexity. Mathematics always defeats physics.

The Golden Law of Performance

The image above visualizes our foundational performance formula:

Think of it this way:

Algorithm Efficiency: Is your road a winding, muddy trail ($O(n^2)$) or a 10-lane highway ($O(1)$)?
Language Overhead: Is your vehicle a bicycle (High Overhead/Interpreter) or a jet (Low Overhead/Compiled/APCu)?

You don't need a faster vehicle (Go/Rust) if you are driving on a muddy road (poor SQL indexing/N+1 queries). Mathematics (the highway) will make the bicycle (PHP) arrive faster than the jet (C++) on the muddy road.

What Problem Does This Solve?

This Bible is for you if you have ever:

❌ Deployed an app that worked perfectly in development but crashed under production load.
❌ Wondered why a simple User::all() brings down a server with 50,000 users.
❌ Spent 3 AM debugging an “N+1 query” you didn’t know existed.
❌ Been told to “just add more servers” when the real problem was a missing database index.

A Sneak Peek Inside

The guide covers 30 crucial topics across three volumes (Volume I, II, and IV), including over 200 code examples. Here are a few high-impact gems:

🚀 Route Caching (Tuning Kit #02): Learn how php artisan route:cache cuts 35ms down to 2ms per request. Free, instant performance.
🗑️ Queue Serialization Trap (Tuning Kit #06): Stop dispatching full Eloquent models ($user) to your queue. You're bloating your Redis instance and risking stale data. Dispatch the ID instead.
💾 Hydration Hell (Tuning Kit #05): Learn why Eloquent models consume 5-10x more memory than raw database arrays (DB::table()) and when to switch.
🏗️ Read/Write Splitting (Tuning Kit #10): Architecturally double your database capacity using Master for writes and Replicas for reads.

🚨 The "10 Production Disasters" Checklist

In Topic 15, I outline the most common architectural mistakes that cause production failures. Make sure your system isn't doing them:

Missing DB Indexes: A death sentence on large tables. (5s search vs. 0.001s).
DB::enableQueryLog() in Production: Guaranteed OOM (Out Of Memory) crash after a few hours of load.
env() after config:cache: All environment variables will return null, causing database connection failures.
Logging Log::info() inside loops: 10,000 logs in a loop is 10,000 unnecessary, expensive I/O operations. Batch them instead.

Access the Full Bible

The full 30-topic text is completely free, open-source, and deployment-ready.

Start engineering faster Laravel systems today:

👉 Read the Bible Here: https://ezmu.github.io/performance-bible/

Let's stop blaming the tools and start designing better roads.

About the Author:
I am Ez-Eldeen Mushtaha, a Software & Systems Architect based in Gaza, Palestine. You can connect with me on LinkedIn
and find more of my work on GitHub and Medium.

A Programmer’s Inferno — Circle Five:The Psychology of Distraction

Ez Eldeen Mushtaha - @ezmu — Tue, 19 May 2026 20:34:40 +0000

14 years ago, I refused to build a fake progress bar for a Java Swing app.

Or even just count the downloaded update files and call that "progress."

It would have been easier. Faster. Less code.

But I didn't.

Because it felt wrong to deceive the user.

Today?

Skeleton loaders. Shimmer effects. Fake spinners.

All "best practices." All "UX improvements."

What I rejected for ethical reasons is now taught to beginners as "how to do it right."

This isn't progress. This is rock bottom.

📖 A Programmer's Inferno — Circle Five: The Psychology of Distraction

A Programmer’s Inferno

A Programmer’s Inferno: We Didn't Notice Software Rotting—Until It Was Too Late!

Ez Eldeen Mushtaha - @ezmu — Tue, 19 May 2026 14:01:43 +0000

The software industry is in crisis, and we are responsible. We've traded architectural discipline for convenience, and engineering wisdom for bloat.

My series, "A Programmer's Inferno," is a descent into the circles of hell that define modern development. Here is the catalog of the first four circles:

Circle I: Architectural Collapse – How we build massive frameworks to solve simple problems, ensuring our systems are broken from day one.
Link: Architectural Collapse

Circle II: Dependency Hell – The culture that compels us to pull in thousands of unknown packages just to execute ten lines of code.
Link: Dependency Hell

Circle III: The Docker Absurdity – Masking software failures behind gigabytes of container overhead.
Link: The Docker Absurdity

Circle IV: Cloud Conspiracy & Jevons Paradox – Why the business model of cloud providers relies on our inefficiency.
Link: Cloud Conspiracy & Jevons Paradox

This isn't just about slow code. It's about planetary energy consumption, digital waste, and the loss of professionalism in our craft.

It's time to stop being "tool operators"—blindly assembling components we don't understand—and start being engineers again.

Circle Five: The Psychology of Distraction is coming next.

Which circle do you see most often in your daily work? Drop your worst "bloat" story in the comments.