Forem: Edna112

Keep The System Alive

Edna112 — Fri, 24 Apr 2026 08:47:28 +0000

The bug wasn’t in the code.

It was in the traffic.

A friend showed me his metrics after a product launch.

Nothing unusual in the logs. No obvious errors, Just one thing:

A sudden spike in requests. Seconds later…The system went down.

The problem

The system tried to handle every request immediately.

No limits.

No control.

What was happening?

When traffic increased:

• every request hit the API

• every request hit the database

• every process started at once

The system didn’t slow down. It overloaded. Why this is dangerous:

Traffic spikes are normal.

But without control:

Your system becomes unstable under pressure.

The solution

You don’t just scale systems, You regulate them.

Two key strategies:

Rate limiting

• restrict how many requests a client can send

• protect your system from abuse or spikes

Backpressure

• control how much work your system processes internally

• queue, delay, or reject excess load

Together, they do one thing:

Keep your system stable under pressure.

Mental model

Think of a highway during rush hour. Without traffic lights or limits… Everything stops. Control the flow…And movement continues.

The lesson

Performance isn’t just about speed, It’s about control.

Takeaway

A stable system doesn’t accept everything.

It knows when to say:

“Not now.”

backend #systemdesign #scalability #softwareengineering #laravel

The Database Bottleneck

Edna112 — Wed, 22 Apr 2026 10:50:05 +0000

“It was fast… until users showed up.”

That’s what I told a friend when we were debugging his system.

Everything looked good at the start. Few users, Fast responses, Clean architecture. Then traffic increased.

And suddenly…

Everything slowed down.

Not crashed.

Just… slower.

The problem

Every request depended on the database. Each time a user did anything:

• fetch data

• update records

• check balances

The system went straight to the database. At small scale? No issue.

At scale? Every request starts competing. What was happening?

The database became the bottleneck.

Too many reads.

Too many writes.

Too many queries happening at the same time. And unlike your app servers…

You can’t scale a database infinitely.

Why this is dangerous

The system still works. But users start feeling:

• slow responses

• delays

• timeouts

And performance keeps getting worse as you grow.

The solution

You don’t remove the database. You reduce how much you depend on it.

Real systems do this by:

• caching frequently read data

• using read replicas for heavy reads

• optimizing queries and indexes

• moving heavy tasks to background jobs

The goal is simple:

Don’t hit the database unless you have to.

Mental model

Think of the database like a single cashier.

At first, no line. Then more people arrive. Now everyone is waiting…Even though the cashier is working perfectly.

The lesson

Your system doesn’t slow down because it’s broken.

It slows down because everything depends on one thing.

Takeaway

Scalable systems don’t just handle more users.

They reduce pressure on their most critical parts.

backend #systemdesign #softwareengineering #scalability #databases

Let's Talk About idempotency

Edna112 — Tue, 21 Apr 2026 02:38:59 +0000

“The payment went through twice.”

That’s what my friend told me.

We were talking about a system he was building.Everything looked fine.

Payments were working. Users were happy. Until one day. Someone got charged twice. No crash,No error Just the same request…Processed twice.

The problem

In real systems, requests don’t always happen once.

They get:

• retried by the client

• resent after timeouts

• triggered twice by impatient users

The system didn’t understand that. So it did exactly what it was told.

Twice.

What was happening?

The system treated every request as new. It had no memory of what it had already processed. So when the same request came in again…It processed it again.

Why this is dangerous

Nothing breaks. Everything “works”.

But now you have:

• duplicate payments

• duplicate orders

• inconsistent data

And once money is involved… That’s a serious problem.

The solution

Design your system to be idempotent.

Meaning:

The same request can be sent multiple times…But only processed once.

Real systems do this by:

• attaching a unique request ID (idempotency key)

• storing processed requests

• rejecting or reusing previous results

So even if the request comes in twice…The outcome stays the same.

Mental model

Think of it like submitting a form with a reference number.

If you submit it again with the same number…

The system knows:

“I’ve already handled this.”

The lesson

In distributed systems, retries are normal.

Duplicate effects should not be.

Takeaway

Your system shouldn’t just handle success.

It should handle being asked to do the same thing… twice.

Have you ever seen a system charge twice or create duplicate data?

backend #systemdesign #architecture #softwareengineering #laravel

EVENTUAL INCONSISTENCY

Edna112 — Mon, 20 Apr 2026 11:08:43 +0000

The system didn’t crash. But two parts of it disagreed. Everything looked normal. Requests were fast. No errors, No alerts. Then something subtle happened. A user checked their data from two different endpoints.Same request. Different answers,outdated. Not random. Just… inconsistent.
The problem
The system wasn’t behaving like a single system. It was behaving like multiple independent parts.
What was happening?
In distributed systems:
There is no single source of truth at every moment.
Different services, replicas, or nodes…
Can see different versions of the same data.
So two parts of your system can both be Correct. But not aligned.
Why this is dangerous
Nothing fails.
Nothing crashes.
But your system starts to:
• contradict itself
• confuse users
• break trust
And the worst part?
It’s working exactly as designed.
The solution
You don’t assume consistency.
You define it.
Real systems make explicit choices:
• Decide where strong consistency is required
• Accept temporary inconsistency where it’s safe
• Design flows that tolerate delayed synchronization
• Ensure critical paths never rely on conflicting data
Mental model
Think of a team without synchronization. Everyone is working. Everyone is doing their job. But without alignment…They produce conflicting results.
The lesson
Distributed systems don’t naturally agree.
Agreement is something you design.
Takeaway
A system isn’t reliable because it works.
It’s reliable because it stays consistent across its parts.

backend #systemdesign #architecture #softwareengineering #laravel