DEV Community: Mehrad Sadeghi

Circuit Breaker Pattern Explained: How to Prevent Cascading Failures in Distributed Systems

Mehrad Sadeghi — Wed, 16 Sep 2026 13:05:24 +0000

Circuit Breaker Pattern

What happens when one service fails, but your entire system keeps calling it anyway ?

Imagine your payment service is down. Normally, every purchase request follows a path like this:

User
 ↓
Order Service
 ↓
Payment Service
 ↓
Bank

Now the Payment Service is unavailable — or perhaps it’s simply extremely slow. A request that normally takes 200 ms now takes 10 seconds. If your system continues sending requests to it, what happens ?

Request queues grow.
Threads and connections remain occupied.
Timeouts increase.
Latency goes up.

And eventually, services that were perfectly healthy can start failing too.

In other words, one failing dependency can potentially bring down an entire system.

This is where the Circuit Breaker pattern comes in.

Instead of continuously calling a dependency that is already failing, the system temporarily stops sending requests to it and fails fast.

The goal isn’t to fix the broken service. The goal is to prevent its failure from spreading.

What Is the Circuit Breaker Pattern ?

The Circuit Breaker is a resilience pattern commonly used in distributed systems to protect services from repeatedly calling an unhealthy dependency.

The idea comes from electrical circuit breakers. When electrical current becomes dangerously high, a circuit breaker interrupts the circuit to prevent further damage.

Software can apply a similar idea:

Healthy dependency
↓
Requests flow
↓
Dependency starts failing
↓
Failure threshold reached
↓
Circuit opens
↓
Requests fail fast

A Circuit Breaker doesn’t repair the dependency.

Instead, it can:

Stop unnecessary requests to a failing service
Protect your own application’s resources
Reduce additional load on the unhealthy dependency
Help prevent cascading failures
Give the dependency time to recover
Allow the system to degrade gracefully when possible

A useful way to think about it is:

Circuit Breaker doesn’t eliminate failure. It prevents failure from becoming a larger system-wide failure.

Why Do Distributed Systems Need Circuit Breakers ?

In a simple monolithic application, you might call a function like:

calculatePrice()

If the function fails, handling the failure is usually relatively straightforward. But distributed systems are different.

A call to another service crosses a network boundary:

Service A
↓
Service B
↓
Service C
↓
External APIService A
↓
Service B
↓
Service C
↓
External API

Unlike a local function call, a remote call can:

Time out
Lose its connection
Become extremely slow
Return a 5xx error
Be rate-limited
Become completely unavailable

And the more important problem is that failure can propagate between services.

For example:

Payment Service
↓
starts failing
↓
Order Service waits
↓
Threads become occupied
↓
Requests start queuing
↓
Latency increases
↓
Error rate increases
↓
The entire service comes under pressure

This is a cascading failure.

The original problem may have started in one service, but the resulting resource exhaustion can spread to otherwise healthy parts of the system.

Circuit Breaker is one of the patterns that can help interrupt this chain.

Reliability, High Availability, and Circuit Breakers

Two concepts often appear in discussions about distributed systems:

Reliability: is about a system behaving dependably in the presence of failures and recovering appropriately when failures occur.

High Availability: is about keeping a system accessible to users even when parts of its infrastructure or dependencies experience problems.

A Circuit Breaker does not make an external service permanently available.

Instead, it can help isolate its failure:

Dependency Failure
↓
Circuit Breaker
↓
Failure Isolation
↓
Graceful Degradation
↓
System remains responsive

This is where the idea of failure isolation becomes important.

Instead of allowing one dependency’s failure to spread across the entire system, we try to limit its blast radius.

How Does a Circuit Breaker Work ?

A Circuit Breaker is commonly modeled as a state machine with three primary states:

Closed
Open
Half-Open

CLOSED - Everything Is Normal

When the Circuit Breaker is CLOSED, requests are allowed to reach the dependency.

Client
↓
Circuit Breaker
↓
Payment Service

The Circuit Breaker monitors the results of those requests. For example:

100 requests
95 successes
5 failures

If the failure rate exceeds the configured threshold, the circuit transitions to OPEN.

But an important detail is that a failure threshold doesn’t necessarily mean:

Five requests failed consecutively.

The threshold can be based on different measurements, such as:

Number of failures
Failure percentage
Number of timeouts
Failures within a time window
A combination of multiple metrics

For example:

50 failures in the last 100 requests

or:

Failure Rate > 30% during the last 30 seconds

The right threshold depends on the actual behavior of the dependency and the reliability objectives of your system. There is no universal magic number.

OPEN - Stop Calling the Failing Service

When the Circuit Breaker transitions to OPEN, its behavior changes completely.

Before:

Request
↓
Circuit Breaker
↓
Payment Service

After:

Request
↓
Circuit Breaker
↓
FAIL FAST

The request never reaches the Payment Service. This is the central idea behind the Circuit Breaker pattern. If we already have strong evidence that a dependency is unhealthy, why should every new request wait for another network timeout ?

Suppose the Payment Service has a 10-second timeout. Now imagine 1,000 concurrent requests all waiting for that timeout:

1,000 requests × 10 seconds

A significant amount of your application’s resources can remain occupied simply waiting for a dependency that is already failing.

With an open circuit:

Request
↓
Circuit = OPEN
↓
Immediate failure

The system can reject the request much earlier.

That can help:

Free threads
Preserve connections
Reduce resource consumption
Keep latency more predictable
Prevent additional traffic from reaching the unhealthy dependency

Sometimes failing quickly is better than failing slowly.

But the circuit should not remain open forever. If it did, the system would never discover that the dependency has recovered.

After a configured period, the Circuit Breaker can transition to HALF-OPEN.

HALF-OPEN - Has the Service Recovered ?

This is one of the most subtle parts of the pattern.

Suppose the Payment Service was unavailable, but now appears to be healthy again. Should we immediately send all traffic back to it ?

Not necessarily. The service may have recovered only partially. For example, it might have just restarted and currently be capable of handling only a small amount of traffic.

Instead of immediately allowing thousands of requests through, the Circuit Breaker can allow a limited number of test requests.
For example:

HALF-OPEN
↓
5 test requests
↓
Are they successful ?

If the requests succeed:

HALF-OPEN
↓
Successful requests
↓
CLOSED

The circuit returns to normal operation.

If the test requests fail:

HALF-OPEN
↓
Failure
↓
OPEN

The circuit opens again.

Why Does HALF-OPEN Allow Only a Few Requests ?

Because service recovery doesn’t necessarily mean full recovery. Imagine a Payment Service that was down and has just come back online. It might currently be capable of processing only:

20 requests / second

If your system suddenly sends:

10,000 requests

you could create another overload:

Recovery
↓
Traffic spike
↓
Overload
↓
Failure again

In other words, your system can accidentally overwhelm the dependency immediately after it recovers.

Half-Open provides a controlled way to test recovery:

Instead of:

0 requests
↓
10,000 requests

we can do:

0 requests
↓
A few test requests
↓
Evaluate results
↓
Gradually increase traffic

The exact number of test requests is implementation- and system-dependent. There is no universal value that works for every architecture.

A Real-World Scenario: Payment Service Failure

Let’s put everything together. Imagine an online store:

User
↓
Order Service
↓
Payment Service
↓
Bank Gateway

Under normal conditions:

Order Service
↓
Circuit Breaker
↓
Payment Service
↓
Bank

Everything is working normally.

Step 1: The Failure Starts

The Bank Gateway begins experiencing problems. The Payment Service starts timing out:

Payment Request
↓
Timeout

The Circuit Breaker records these failures.

Step 2: The Failure Threshold Is Reached

Suppose our policy is:

100 requests
40 failures

and our configured rule is:

Failure Rate > 30% → OPEN

The threshold has been exceeded. The Circuit Breaker opens.

Step 3: New Requests Fail Fast

Now a new request arrives:

User
↓
Order Service
↓
Circuit = OPEN
↓
Immediate Failure

The Order Service no longer calls the Payment Service.

This prevents the application from repeatedly waiting for a dependency that is already known to be unhealthy.

Step 4: The System Degrades Gracefully

Once the circuit is open, the system still has to decide what the user should experience. For example:

Payment is temporarily unavailable. Please try again in a few minutes.

Or the application might have another valid strategy:

Keep the order in a PENDING state
Put the operation into a queue
Switch to another payment provider
Return non-critical information from a cache

This is where fallback becomes important.

What Is a Fallback?

A fallback answers a simple question:

If the primary path fails, do we have a meaningful alternative ?

For example:

Primary Payment Provider
↓
FAILED
↓
Secondary Payment Provider

But a fallback is not always possible. For a payment operation, you cannot simply return Payment successful, when the payment was never actually processed.

The fallback must therefore be consistent with the business logic. A fallback is not a fake success. It is an alternative behavior that is safe and meaningful for that particular operation.

Circuit Breaker ≠ Retry

These two concepts are often confused. They solve different problems.

Retry says:

The request failed. Maybe trying again will succeed.

Circuit Breaker says:

This dependency has been failing repeatedly. Stop sending requests to it for now.

Retry can be useful for transient failures, such as:

Temporary network glitch
Temporary timeout
Temporary throttling

But if the dependency is genuinely down, excessive retries can make the situation worse.

How Retries Can Cause a Cascading Failure

Suppose you have 1,000 requests and every failed request is retried three times. You might end up with:

1,000 original requests + 3,000 retries = 4,000 requests

That’s exactly what you don’t want when the dependency is already overloaded.

Now imagine:

A → B → C

Service C fails. Service B retries its requests to C. Service A retries its requests to B.

The result can look like this:

C fails
↓
B retries
↓
A retries
↓
More traffic
↓
C becomes even more overloaded
↓
More failures
↓
Cascading failure

This can lead to a retry storm.

So should we eliminate retries ?

No. The problem isn’t retrying itself. The problem is uncontrolled retries. A more resilient design might combine:

Request
↓
Timeout
↓
Retry
↓
Exponential Backoff + Jitter
↓
Circuit Breaker

The important point is that retries should generally be limited to failures where another attempt has a reasonable chance of succeeding.

For example, retrying a transient 503 Service Unavailable may make sense in some systems.

Retrying a 401 Unauthorized generally does not solve the underlying problem.

Exponential Backoff and Jitter

Imagine 10,000 requests fail at approximately the same time. If every client retries exactly one second later:

1 second
↓
10,000 requests

You’ve created another traffic spike.

With exponential backoff, the delay between retries increases:

1s
2s
4s
8s
…

This helps spread retries over a longer period.

But there’s still a problem. If every client follows exactly the same schedule, they can still retry at roughly the same moments. That’s where jitter helps.
Instead of:

1s
2s
4s
8s

different clients might retry at slightly different times:

1.2s
1.8s
2.4s
3.1s
…

The goal is to spread retry traffic instead of allowing thousands of clients to synchronize their retries.

Idempotency: The Problem You Must Consider When Retrying

Retries introduce another important problem: duplicate side effects.
Imagine:

POST /payments

The request reaches the Payment Service. The payment is successfully processed. But the response is lost because of a network failure. What does the client see?

Timeout

From the client’s perspective, it doesn’t know whether the payment succeeded. So it retries:

POST /payments

Now you potentially have:

Request #1 → Payment successful
↓
Response lost
↓
Retry
↓
Request #2 → Payment successful again

You may have charged the customer twice. This is where idempotency becomes critical. For example, the client could send an idempotency key:

Idempotency-Key: ABC123

The Payment Service can use that key to recognize that the same logical operation has already been processed.

Conceptually:

Retry
↓
Same Idempotency Key
↓
Same Logical Operation
↓
No Duplicate Side Effect

Therefore, whenever you introduce retries, ask:

Is this operation actually safe to retry ?

Important Circuit Breaker Configuration Parameters

Implementing a Circuit Breaker isn’t simply a matter of adding an if statement. Several parameters need to be defined.

1. Failure Threshold

How many failures should cause the circuit to open ?
For example:

Failure Rate > 50%

A threshold that is too low may cause the circuit to open because of temporary failures.

A threshold that is too high may allow the dependency to cause significant damage before the circuit reacts.

2. Recovery Timeout

Once the circuit is open, how long should we wait before testing the dependency again ?

For example:

30 seconds

A timeout that is too short can produce this cycle:

OPEN
↓
HALF-OPEN
↓
Failure
↓
OPEN
↓
HALF-OPEN
↓
…

On the other hand, a timeout that is too long may prevent requests from reaching a dependency even after it has recovered.

3. Number of HALF-OPEN Requests

When the circuit enters HALF-OPEN, how many requests should be allowed through ?

For example:

1 request

or:

5 requests

or a limited percentage of traffic.

Allowing more requests can provide more information about recovery, but it also creates more load on the recovering dependency.

4. Which Failures Should Open the Circuit ?

Not every error should necessarily be treated as evidence that a dependency is unhealthy.

For example:

Timeout → likely relevant
503 → likely relevant
Connection error → likely relevant
401 → probably not
400 → probably not

If every 4xx error contributes to the Circuit Breaker threshold, you could incorrectly conclude that the entire dependency is unavailable.

Circuit Breaker Has a Cost Too

No resilience pattern is free. Circuit Breaker provides important benefits, but it also introduces complexity.

Potential benefits

Helps prevent cascading failures
Reduces load on an unhealthy dependency
Enables fail-fast behavior
Protects application resources
Supports graceful degradation
Improves system resilience
Enables controlled recovery

Potential costs

More application complexity
Additional monitoring requirements
Threshold tuning
State management
Fallback design
More difficult debugging
False positives
False negatives

For example, if your threshold is too sensitive:

Temporary failure
↓
Circuit opens
↓
Requests rejected

even though the dependency wasn’t actually down. If the threshold is too permissive:

Dependency is failing
↓
Circuit remains CLOSED
↓
More failures
↓
More resource consumption

So configuring a Circuit Breaker is a trade-off, not a search for one perfect number.

Where Should the Circuit Breaker Live ?

A common placement is close to the remote call:

Order Service
↓
Circuit Breaker
↓
Payment Service

This keeps the decision close to the dependency being protected.

However, Circuit Breaking can also be implemented at other layers, depending on the architecture:

Application layer
API Gateway
Service Mesh
Sidecar

A Service Mesh for example, can provide resilience features without requiring every application to implement the same logic. But that introduces another trade-off. Moving more resilience behavior into infrastructure can simplify application code, while potentially making debugging and understanding system behavior more complicated.

Do You Always Need a Circuit Breaker ?

No.

Circuit Breaker is not automatically appropriate for every operation.

For example:

function calculateTax()

If this is a local, fast operation with no meaningful remote dependency, adding a Circuit Breaker may simply introduce unnecessary complexity.

Circuit Breakers become more interesting when dealing with things such as:

Remote APIs
External providers
Database dependencies
Microservices
Third-party services

The key question isn’t:

Do we use microservices ?

The better question is:

What happens to our system when this dependency becomes slow, unavailable, or unreliable ?

Circuit Breaker Alone Is Not Resilience

One common misconception is Circuit Breaker = Resilience. It isn’t.

Circuit Breaker is only one tool in a broader resilience strategy.

A more complete design might look like:

     ┌─────────────┐
     │   Timeout   │
     └──────┬──────┘
            ↓
     ┌─────────────┐
     │    Retry    │
     └──────┬──────┘
            ↓
┌───────────────────────┐
│ Exponential Backoff   │
│       + Jitter        │
└───────────┬───────────┘
            ↓
    ┌─────────────┐
    │   Circuit   │
    │   Breaker   │
    └──────┬──────┘
           ↓
    ┌─────────────┐
    │  Fallback   │
    └─────────────┘

Depending on the system, other patterns and mechanisms may also be relevant:

Resilience usually comes from combining the right mechanisms, not from adding one pattern everywhere.

How Do You Know Your Circuit Breaker Is Working ?

A Circuit Breaker without observability is difficult to operate. At a minimum, you should be able to monitor metrics such as:

Circuit state
Failure rate
Success rate
Timeout rate
Number of circuit openings
Half-Open attempts
Recovery time
Fallback rate
Request latency

State transitions can also be important monitoring events.
For example:

Circuit: CLOSED → OPEN

This may indicate a significant problem with an external dependency.

Without monitoring, you may know that requests are failing — but not know why the Circuit Breaker opened, how often it opens, or whether it is actually helping.

The Goal Isn’t to Eliminate Errors

This is one of the most important ideas behind the pattern. A Circuit Breaker does not necessarily reduce the number of errors users see. In fact, after a circuit opens, you may see more immediate failures. But those failures can be much more controlled.

Without a Circuit Breaker:

1,000 requests
↓
1,000 timeouts
↓
10 seconds each
↓
Thread exhaustion
↓
Entire service becomes unhealthy

With a Circuit Breaker:

1,000 requests
↓
Circuit OPEN
↓
1,000 fast failures
↓
Dependency protected
↓
Main service remains responsive

In both cases, there are failures. But the second scenario prevents those failures from consuming resources indefinitely. That’s the key distinction.

The goal of a Circuit Breaker isn’t to make failure disappear. It’s to turn an uncontrolled failure into a controlled one.

And that is one of the fundamental ideas behind resilient distributed systems.

The State Machine in One Picture

Let’s summarize the state transitions:

CLOSED: Requests are allowed through.

CLOSED
↓
Requests flow normally

If failures exceed the configured threshold:

CLOSED → OPEN

OPEN: Requests fail fast without calling the dependency.

OPEN
↓
Fail Fast

After the configured recovery timeout:

OPEN → HALF-OPEN

HALF-OPEN: A limited number of test requests are allowed.

If recovery succeeds:

HALF-OPEN → CLOSED

If the dependency fails again:

HALF-OPEN → OPEN

So the complete lifecycle is:

Image by geeksforgeeks

The Bigger Lesson

It’s useful to remember the three states, But understanding why they exist is much more important.

When a dependency is failing, continuing to send more requests isn’t necessarily resilience. Sometimes the most resilient thing your system can do is stop making the problem worse.

Circuit Breaker, together with carefully designed timeouts, limited retries, exponential backoff, jitter, fallback strategies, and idempotency, can help prevent a localized dependency failure from turning into a much larger outage.

The central idea is simple:

When a dependency is unhealthy, protect your system first — and give the dependency a controlled chance to recover.

Final Takeaway

The Circuit Breaker pattern is a resilience mechanism for systems that depend on remote services or external resources where failures, timeouts, and temporary unavailability are possible.

Its three primary states are:

CLOSED
↓
Requests flow normally

OPEN
↓
Requests fail fast

HALF-OPEN
↓
A limited number of requests test recovery

The most important lesson isn’t memorizing these states. It’s understanding the philosophy behind them:

A resilient system doesn’t just know how to handle failure. It knows when to stop making a failure worse.

A Final Thought Experiment

Imagine your Payment Service is completely down. Your system receives 10,000 payment requests per minute. Which behavior makes more sense ?

Option 1: Retry every request three times.
Option 2: Open the Circuit Breaker after the failure rate crosses the configured threshold and fail fast.
Option 3: Use a combination of:

The interesting part isn’t memorizing which pattern to use. The real engineering challenge is understanding how these mechanisms interact under failure. That’s where resilient distributed-system design begins.

MySQL Overselling: Why SELECT Isn't Enough and How SELECT ... FOR UPDATE Solves It

Mehrad Sadeghi — Sun, 13 Sep 2026 14:51:03 +0000

Imagine you’re running an online store, there’s exactly one item left in stock. Two customers click Buy at almost exactly the same time. Both requests reach your application. Both transactions ask the database:

SELECT stock FROM products WHERE id = 10;

And both get:

stock = 1

Now both customers believe the product is available.

So what happens next ? Welcome to the overselling problem.

The Naive Implementation

A simple purchase flow might look like this:

START TRANSACTION;
SELECT stock FROM products WHERE id = 10;
-- Application checks:
-- Is stock > 0 ?
UPDATE products SET stock = stock - 1 WHERE id = 10;
INSERT INTO orders (product_id, user_id) VALUES (10, 1001);
COMMIT;

At first glance, this seems perfectly reasonable. But there’s a race condition.

Imagine two transactions:

Transaction A              Transaction B

SELECT stock               SELECT stock
     |                           |
     v                           v
   stock=1                    stock=1
     |                           |
     v                           v
"Available!"                 "Available!"

Both transactions read the same value before either one has completed the purchase. The problem isn’t necessarily that MySQL is broken. The problem is that our read and decision are not protected as one atomic operation.

Why Doesn’t REPEATABLE READ Solve This ?

This is an important question. InnoDB’s default isolation level is REPEATABLE READ. So you might think:

“If I’m using REPEATABLE READ, shouldn’t MySQL prevent this ?”

Not necessarily.

A normal:

SELECT ...

is a consistent, nonlocking read.

Under REPEATABLE READ, it can read from the transaction's consistent snapshot.

Isolation determines what your transaction sees. It doesn’t automatically mean:

“Nobody else can modify the row after I read it.”

That’s a completely different requirement.

If your business operation is:

“Read this row, verify a condition, and then modify it.”

you often need a locking read.

Enter SELECT … FOR UPDATE

MySQL provides:

SELECT ... FOR UPDATE

For example:

START TRANSACTION;
SELECT stock FROM products WHERE id = 10 FOR UPDATE;

This is not just a normal read. It is a locking read.

MySQL/InnoDB locks the records returned by the query, and another transaction attempting to acquire a conflicting lock on the same records has to wait until the first transaction commits or rolls back.

Now our two transactions look very different.

Transaction A Gets There First

Suppose Transaction A executes:

START TRANSACTION;
SELECT stock FROM products WHERE id = 10 FOR UPDATE;

The database finds:

stock = 1

and locks the relevant record.

Transaction B now tries:

SELECT stock FROM products WHERE id = 10 FOR UPDATE;

But Transaction A is already holding the conflicting lock.

So Transaction B waits.

Transaction A                 Transaction B
FOR UPDATE
     |
     v
 stock = 1
     |
  LOCK ROW
     |
     |                       FOR UPDATE
     |                            |
     |                            v
     |                         WAIT...
     |
 UPDATE stock = 0
     |
 INSERT ORDER
     |
   COMMIT
     |
  UNLOCK
                                |
                                v
                          FOR UPDATE succeeds

Now Transaction B gets its turn.

The important part is that Transaction B doesn’t get to make its decision before Transaction A finishes.

The Correct Purchase Flow

A safer implementation looks like this:

START TRANSACTION;
SELECT stock FROM products WHERE id = 10 FOR UPDATE;

Then the application checks the returned value:

if stock > 0:
    continue purchase
else:
    reject purchase

If stock is available:

UPDATE products SET stock = stock - 1 WHERE id = 10;
INSERT INTO orders (product_id, user_id) VALUES (10, 1001);
COMMIT;

If the product is already sold out:

ROLLBACK;

The important property is that the check and subsequent modification happen while the relevant row is locked.

The Key Idea: Lock Before You Decide

This is the mental model worth remembering:

Unsafe:

READ
  ↓
CHECK
  ↓
UPDATE

The problem is that another transaction can interfere between the read and the update.

Safer:

LOCK + READ
     ↓
   CHECK
     ↓
   UPDATE
     ↓
   COMMIT

The lock protects the critical section.

But There’s Another Option

For a simple inventory decrement, you don’t always need to read the row first. You can make the condition part of the update itself:

UPDATE products SET stock = stock - 1 WHERE id = 10 AND stock > 0;

Then check how many rows were affected.

If:

affected_rows = 1

the purchase can proceed.

If:

affected_rows = 0

there wasn’t enough stock.

This approach can be extremely useful because the business condition is enforced directly by the database operation.

For example:

START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE id = 10 AND stock > 0;
-- If one row was updated:
-- create the order
INSERT INTO orders (product_id, user_id) VALUES (10, 1001);
COMMIT;

In a real implementation, the application should only insert the order when the update actually succeeded.

So When Should You Use SELECT … FOR UPDATE ?

SELECT ... FOR UPDATE is particularly useful when your business logic needs to:

Read the current state of a row.
Make a decision based on that state.
Modify that same data.
Keep another transaction from changing it between those steps.

Common examples include:

inventory reservation
seat reservation
wallet balance updates
account transfers
job claiming
resource allocation
order processing

For example:

SELECT balance FROM accounts WHERE id = 123 FOR UPDATE;

Then:

Check balance
     ↓
Calculate new balance
     ↓
UPDATE account
     ↓
COMMIT

The lock protects the critical decision.

A Common Misunderstanding

One common misconception is:

“FOR UPDATE locks the entire table."

That’s not generally how InnoDB works.

InnoDB uses row-level locking, although the exact locks acquired depend on the query, indexes, search conditions, and isolation level. For some range queries, InnoDB can also use gap locks or next-key locks.

For example, a unique-index lookup such as:

SELECT stock FROM products WHERE id = 10 FOR UPDATE;

can lock the matching index record.

Range-based locking is more complicated.

For example:

SELECT * FROM products WHERE price BETWEEN 100 AND 200 FOR UPDATE;

may involve range-related locking behavior depending on the indexes and isolation level.

This is one reason understanding indexes is important when reasoning about MySQL concurrency.

Don’t Forget the Transaction

FOR UPDATE makes sense inside a transaction.

For example:

START TRANSACTION;
SELECT stock FROM products WHERE id = 10 FOR UPDATE;
UPDATE products SET stock = stock - 1 WHERE id = 10;
INSERT INTO orders (product_id, user_id) VALUES (10, 1001);
COMMIT;

The lock is part of the transaction’s concurrency control. You don’t want to acquire a lock, perform a tiny operation, release it, and then perform the critical business operation later. The entire critical section should be designed intentionally.

What About Deadlocks ?

Locks solve one class of concurrency problems, but they introduce another possibility: deadlocks.

Imagine:

Transaction A                 Transaction B
locks Row 1                   locks Row 2
     |                              |
     v                              v
tries Row 2                    tries Row 1
     |                              |
     +---------- WAIT <-------------+

Now both transactions are waiting for each other.

InnoDB detects deadlocks and rolls back one of the transactions so that the other can continue.

This means production applications using transactions and locks should generally be prepared to retry transactions when appropriate.

Locking isn’t something you simply add without considering transaction boundaries, lock ordering, indexes, and failure handling.

The Real Lesson

The important lesson isn’t simply:

“Use SELECT ... FOR UPDATE."

The deeper lesson is:

Concurrency bugs happen when a business decision depends on data that can change between the read and the write.

You need to identify that critical section and choose an appropriate concurrency-control strategy.

Sometimes that’s:

SELECT ... FOR UPDATE

Sometimes it’s an atomic conditional update:

UPDATE ... WHERE stock > 0;

Sometimes it’s an optimistic concurrency strategy. And sometimes a database constraint is the best solution. The correct choice depends on the business operation.

Final Takeaway

When building a system that handles concurrent requests, don’t ask only:

“Which isolation level should I use ?”

Also ask:

“What happens if two transactions execute these exact statements at the same time ?”

That’s the question that exposes race conditions.

For an inventory operation, this:

SELECT stock FROM products WHERE id = 10;

and this:

SELECT stock FROM products WHERE id = 10 FOR UPDATE;

are not equivalent.

The first reads. The second reads with an intention to modify and acquires a lock.

Once you understand that distinction, MySQL transaction isolation becomes much easier to reason about.

And more importantly, you can start designing systems that remain correct even when thousands of users click Buy at exactly the same time.

Two Transactions, One Row: What Does MySQL Actually Let You See ?

Mehrad Sadeghi — Sun, 13 Sep 2026 14:47:01 +0000

Two users, One database row, Both reading and writing at almost exactly the same time. Who sees what ?

Can one transaction see another transaction’s uncommitted changes ?
Can the same query return different results inside a single transaction ?
And why does SELECT sometimes give you a snapshot, while SELECT ... FOR UPDATE
gives you something completely different ?

If you’ve ever wondered what MySQL actually does when transactions run concurrently, this is where it gets interesting.

InnoDB gives you four transaction isolation levels:

READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE

Most developers know their names, fewer can predict what will actually happen when two transactions execute at the same time.

That’s what we’re going to do here.

No abstract definitions first. No memorizing a table. We’ll make the transactions collide and see what MySQL does.

Why Do We Need Transactions ?

Consider a typical e-commerce purchase. When a customer buys a product, several database operations may need to happen together:

Check the product inventory.
Decrease the inventory.
Create the order.
Record the payment.
Update the order status.

What happens if the inventory is successfully decreased but creating the order fails ?

You could end up with a database where the product’s inventory has decreased, but no corresponding order exists.

That’s exactly the kind of problem transactions are designed to prevent.

A transaction lets us treat multiple database operations as a single logical unit:

Either all of the operations succeed, or the changes are rolled back.

For example:

START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE id = 10;
INSERT INTO orders (product_id, user_id) VALUES (10, 1001);
COMMIT;

If something goes wrong:

ROLLBACK;

Transactions are one of the foundations of ACID, and the I in ACID stands for Isolation. Isolation is where things get interesting.

What Is a Transaction Isolation Level ?

Imagine two transactions running at approximately the same time:

Transaction A                Transaction B
      |                            |
      |---- read data ------------>|
      |                            |
      |                       update data
      |                            |
      |<--- what can A see ? ------|

Both transactions may be reading and modifying the same data. The isolation level defines the rules for what each transaction is allowed to see while other transactions are running.

Those rules can dramatically change the behavior of your application.

For example:

Can you see another transaction’s uncommitted changes ?
Can the same query return a different value later ?
Do you keep seeing the same snapshot ?
Does your read lock the row ?
Can another transactions modify the row while you’re making a decision ?

Let’s find out.

1. READ UNCOMMITTED - When Uncommitted Data Becomes Visible

READ UNCOMMITTED is the least restrictive isolation level. A transaction can potentially see changes made by another transaction before those changes have been committed. This is known as a dirty read.

Suppose the database contains:

stock = 10

Transaction A starts:

START TRANSACTION;
UPDATE products SET stock = 0 WHERE id = 10;

But Transaction A hasn’t committed yet.

Now Transaction B executes:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;
SELECT stock FROM products WHERE id = 10;

Transaction B may see:

Wait. That 0 hasn't actually been committed.

Now Transaction A rolls everything back:

ROLLBACK;

The actual value goes back to:

Transaction B just observed a value that never became part of the committed database state. That’s a dirty read.

Why is this dangerous ?

Imagine applying the same idea to:

payments
bank balances
inventory
orders
seat reservations

You could make a business decision based on data that ultimately disappears. A simple way to remember it:

READ UNCOMMITTED: you get more concurrency by giving up consistency.

2. READ COMMITTED - Only See What Has Been Committed

READ COMMITTED takes a more conservative approach. A transaction doesn’t see another transaction’s uncommitted changes through a normal consistent read. But there’s a catch.

The data you see can change while your transaction is still running.

Suppose:

Initial stock = 10

Transaction A starts:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT stock FROM products WHERE id = 10;

It sees:

Now Transaction B changes the value:

START TRANSACTION;
UPDATE products SET stock = 5 WHERE id = 10;
COMMIT;

Transaction A executes the same query again:

SELECT stock FROM products WHERE id = 10;

This time:

The same transaction saw 10 and later 5. That’s a Non-Repeatable Read.

But why this happens ? Because under READ COMMITTED, each consistent read can establish its own fresh snapshot.

When is READ COMMITTED useful ?

It’s a good fit for systems where seeing relatively fresh committed data is more important than maintaining one consistent snapshot throughout the entire transaction.

It also changes InnoDB’s locking behavior. For locking READ, UPDATE, and DELETE, InnoDB generally uses record locks rather than gap locks, except where gap locking is needed for foreign-key and duplicate-key checks.

A simple way to remember it:

READ COMMITTED: every consistent read sees committed data as of that read, so a later read can see changes committed by other transactions.

3. REPEATABLE READ - Your Transaction Gets a Snapshot

Now we reach InnoDB’s default isolation level: REPEATABLE READ.

Suppose:

stock = 10

Transaction A starts:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT stock FROM products WHERE id = 10;

It sees:

Now Transaction B changes the value:

START TRANSACTION;
UPDATE products SET stock = 5 WHERE id = 10;
COMMIT;

Transaction A runs the same query again:

SELECT stock FROM products WHERE id = 10;

And for a normal, non-locking consistent read, it can still see 10, not 5.

Why is that ? Because consistent reads in a REPEATABLE READ transaction use the transaction's snapshot.

So from Transaction A’s perspective, the database can effectively look like:

Transaction A’s view:

stock = 10

even though the current committed value is now:

stock = 5

4. SERIALIZABLE - Make Concurrency Behave More Like Sequential Execution

SERIALIZABLE is the strictest of the four isolation levels. Its goal is to provide behavior that is closer to transactions executing one after another rather than freely interleaving.

Conceptually:

Transaction A
     |
     | read/write
     |
     v
Transaction B
     |
     | waits
     v
Transaction A commits
     |
     v
Transaction B continues

In InnoDB, when auto-commit is disabled, plain SELECT statements under SERIALIZABLE are implicitly converted to locking reads using FOR SHARE.

This provides stronger consistency guarantees, but the additional locking can reduce concurrency.

So while SERIALIZABLE sounds like the safest choice, it isn't automatically the best choice. Stronger isolation comes with a cost.

A simple way to remember it:

SERIALIZABLE: strongest isolation, but concurrency becomes more expensive.

Comparing the Four Levels

Here’s the quick mental model:

But don’t treat this table as the whole story.

InnoDB’s behavior also involves:

The interesting part isn’t memorizing the table. It’s being able to predict what happens when two transactions collide.

The Bigger Lesson

Here’s the part that matters most in real applications:

Choosing an isolation level doesn’t automatically make your concurrent code correct.

Isolation level determines the visibility and concurrency rules of transactions, But your SQL statements determine how you interact with the data.

Compare:

SELECT stock FROM products WHERE id = 10;

with:

SELECT stock FROM products WHERE id = 10 FOR UPDATE;

They may look almost identical, but they are not.

The first is a consistent read.

The second is a locking read.

And when two requests hit your application at almost exactly the same time, that difference can determine whether your system behaves correctly.

The Question You Should Ask

When debugging or designing concurrent database code, don’t ask only:

“Which isolation level am I using ?”

Ask this instead:

“What happens if two transactions execute these exact statements at the same time ?”

That’s the question that exposes race conditions.

Once you start thinking in terms of concurrent transactions instead of isolated SQL statements, MySQL’s transaction model becomes much easier to understand.

Final Takeaway

Transaction isolation isn’t just a list of four configuration values. It’s a set of rules governing what your transactions can see, when they can see it, and how they interact with other transactions.

If you remember only one thing from this article, remember this:

The real test of your database design isn’t what happens when one transaction runs. It’s what happens when two transactions run at the same time.

And when those two transactions are fighting over the last item in stock, the difference between a normal SELECT and SELECT ... FOR UPDATE suddenly becomes very important.

That’s where we’re going next.

Next: MySQL Overselling - Why SELECT Isn't Enough and How SELECT ... FOR UPDATE Solves It

Clean Code Made Simple - Part 3

Mehrad Sadeghi — Mon, 15 Aug 2022 17:28:54 +0000

Further to my last posts Part 1 and Part 2 of Clean Code Made Simple,
in this post I'm going to continue introducing techniques from Robert C. Martin’s Clean Code book.

#11 Law of Demeter

As wikipedia says:

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. can be succinctly summarized in each of the following ways:

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

Each unit should only talk to its friends; don't talk to strangers.

Only talk to your immediate friends.

Now that we have a basic understanding of Demeter's law, in order to prevent breaking it, which one of the following structures do you think is better?

$ctx->getAbsolutePathOfScratchDirectoryOption();

$ctx->getScratchDirectoryOption().getAbsolutePath()

well non is good. If ctx is an object, we should be telling it to do something; we should not be asking it about its internals.

Consider far from code about (in that module) we needed the outputDir like below:

$outFile = $outputDir + "/" + $className->replace('.', '/') + ".class";
$fout = new FileOutputStream($outFile);
$bos = new BufferedOutputStream($fout);

So, what if we told the ctx object to do this:

$bos = $ctx->createScratchFileStream($classFileName);

That seems like a reasonable thing for an object to do! This allows ctx to hide its internals and prevents the current function from having to violate the Law of Demeter by navigating through objects it shouldn’t know about.

#12 Standard Pattern Names

By using the standard pattern names, such as COMMAND or VISITOR, in the names of the classes that implement those patterns, you can succinctly describe your design to other developers.

#13 Doing One Thing

How do you think we can figure out a function is doing more than “one thing”?

The answer is that if you can extract another function from it with a name that is not merely a restatement of its implementation, Then you would know it's doing more than one thing.

To do so, we need to make sure that the statements within our function are all at the same level of abstraction. for example
getHtml() is at a very high level of abstraction,
$pagePathName = PathParser::render($pagePath); is at intermediate abstraction,
and something like ->append("\n") is at low level of abstraction

#14 Base Class and Derivatives

The most common reason for partitioning concepts into base and derivative classes is so that the higher level base class concepts can be independent of the lower level derivative class concepts. Therefore, when we see base classes mentioning the names of their derivatives, we suspect a problem. In general, base classes should know nothing about their derivatives.

There are exceptions to this rule, of course. Sometimes the number of derivatives is strictly fixed, and the base class has code that selects between the derivatives. We see this a lot in finite state machine implementations. However, in that case the derivatives and base class are strongly coupled and always deploy together. In the general case we want to be able to deploy derivatives and bases separately.

#15 Naming

Methods should have verb or verb phrase names like postPayment, deletePage, or save.
Accessors, mutators, and predicates should be named for their value and prefixed with get,
set, and is.

$name = employee->getName();
$customer->setName("mike");
if ($paycheck->isPosted())...

Okay. This is it for this part. You can join my Telegram channel to get notified of the latest posts. Also, you can follow me on Twitter and LinkedIn.

Clean Code Made Simple - Part 2

Mehrad Sadeghi — Thu, 11 Aug 2022 16:49:00 +0000

Further to my last post Clean Code Made Simple - Part 1, in this post I'm going to continue introducing techniques from Robert C. Martin’s Clean Code book.

#6 Hiding Data

Which one of below code snippets do you think is better designed?

interface Vehicle {
    public function getFuelTankCapacityInGallons();
    public function getGallonsOfGasoline();
}

interface Vehicle {
    public function getPercentFuelRemaining();
}

In both of the above cases the second option is preferable. We do not want to expose the details of our data as much as possible. Rather we want to express our data in abstract terms. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters.

So in any situation where it's suitable to hide the data of an object, You may do it.

#7 Simple Design Rules

Kent Beck introduced these 4 rules as basic criteria to design programs better:

Runs all the tests
Contains no duplication
Expresses the intent of the programmer
Minimizes the number of classes and methods

In an effort to make our classes and methods small, we might create too many tiny classes and methods. we should also keep our function and class counts low. this is the forth rule of simple design rules by kent which is more important than other ones.

#8 Intention Revealing Functions

how do you think this code snippet can get better ?

public function getFlaggedCells() {

    $flaggedCells = new List();

    foreach ($cells as $cell) {
        if ($cell[STATUS_VALUE] == 1) {
            $flaggedCells->add($cell);
        }
    }

    return $flaggedCells;
}

We can write an intention-revealing function (call it isFlagged) to hide the magic numbers. It results in a new version of the function:

public function getFlaggedCells() {

    $flaggedCells = new List();

    foreach ($cells as $cell) {
        if ($cell->isFlagged())
            $flaggedCells->add($cell);

    return $flaggedCells;
}

#9 Writing Tests Leads to Better Designs

Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed. Fortunately, making our systems testable pushes us toward a design where our classes are small and single purpose. Writing tests leads to better designs.

#10 Separation of Concerns

What would you recommend the direction of arrows should be, to separate construction from use ?

Main             Application



Builder

Directions should be as follow:

            run
  Main  --------->  Application
   |
   | build and construct
  \|/
Builder

It simply means that the construction of our application should be separate from using it. These two steps are fundamentally separate and decoupling them gives us a better design and structure.

Okay. This is it for this part. You can join my Telegram channel to get notified of the latest posts. Also, you can follow me on Twitter and LinkedIn.

Clean Code Made Simple - Part 1

Mehrad Sadeghi — Sun, 07 Aug 2022 08:13:00 +0000

I’ve read Robert C. Martin’s Clean Code book a couple of years ago. It’s a great book, Especially for those who are in the junior years of their career. It helps you become a more mature software developer/engineer and write quality code more often.

I aggregated the tips, tricks, and practices I’ve learned from this book and will publish them in multiple parts.

Note that there are quotes and code examples that I’ve used from the original book in this series.

So without further ado, Let’s start.

#1 Short Functions Are Better

What uncle bob says about a function’s length is that the smaller a function is, The better.
He suggests that the block of code inside an if statement, else statement, and while statement should be just one line. Also, the indent level of a function should not be more than one or two.

It’s a good practice if you could do it. It’s not always possible to follow this rule strictly, But try to do it as much as possible.

#2 Introduce Instance Variables When Possible

Passing instance variables instead of primitive parameters into a function is a good idea when it’s proper. But when it’s proper?

Consider a large function with many variables declared within it. Let’s say you want to extract one small part of that function into a separate function. However, the code you want to extract uses four of the variables declared in the function.

This is a situation where passing an instance variable may be a good idea.

class Sample 
{ 
  public function __construct() 
  {

  }

  public function render() 
  {
   // doing some logic
   $this->getHtml($var1, $var2, $var3, $var4);
  }

  private function getHtml($var1, $var2, $var3, $var4) 
  {
   // doing some logic with vars
  }
}

Will become:

class Sample 
{
  private $var;

  public function __construct(VarThing $var) 
  {
   $this->var = $var;  
  }

  public function render() 
  {
   // doing some logic
   $this->getHtml();
  }

  private function getHtml() 
  {
   // $this->var is accessible here
  }
}

#3 The BUILD-OPERATE-CHECK Pattern

You’ve probably heard of Arrange-Act-Assert or AAA pattern before, Which is similar to the Build-Operate-Check pattern.

How do you think we can improve the following code?

public function testGetPageHieratchyAsXml()
{
    crawler()->addPage($root, PathParser()->parse("PageOne"));
    crawler()->addPage($root, 
       PathParser()->parse("PageOne.ChildOne"));
    crawler()->addPage($root, PathParser()->parse("PageTwo"));

    request()->setResource("root");
    request()->addInput("type", "pages");

    $responder = new SerializedPageResponder();
    $response = $responder->makeResponse(
        new FitNesseContext($root), $request
    );

    $xml = $response->getContent();

    assertEquals("text/xml", $response->getContentType());
    assertSubString("<name>PageOne</name>", $xml);
    assertSubString("<name>PageTwo</name>", $xml);
    assertSubString("<name>ChildOne</name>", $xml);
}

public function testGetPageHieratchyAsXmlDoesntContainSymbolicLinks()
{

    $pageOne = crawler()->addPage($root, 
       PathParser()->parse("PageOne"));

    crawler()->addPage($root, 
       PathParser()->parse("PageOne.ChildOne"));
    crawler()->addPage($root, PathParser()->parse("PageTwo"));

    $data = $pageOne->getData();

    $properties = $data->getProperties();
    $symLinks = $properties->set(SymbolicPage::PROPERTY_NAME);

    $symLinks.set("SymPage", "PageTwo");
    $pageOne.commit($data);
    request()->setResource("root");
    request()->addInput("type", "pages");

    $responder = new SerializedPageResponder();
    $response = $responder->makeResponse(
        new FitNesseContext($root), $request);

    $xml = $response->getContent();

    assertEquals("text/xml", $response->getContentType());
    assertSubString("<name>PageOne</name>", $xml);
    assertSubString("<name>PageTwo</name>", $xml);
    assertSubString("<name>ChildOne</name>", $xml);
    assertNotSubString("SymPage", $xml);
}

public function testGetDataAsHtml()
{
    crawler()->addPage($root, PathParser()
           ->parse("TestPageOne"), "test page");
    request()->setResource("TestPageOne");
    request()->addInput("type", "data");
    $responder = new SerializedPageResponder();
    $response = $responder->makeResponse(
        new FitNesseContext($root), $request);
    $xml = $response->getContent();
    assertEquals("text/xml", $response->getContentType());
    assertSubString("test page", $xml);
    assertSubString("<Test", $xml);
}

This is how we can improve it:

public function testGetPageHierarchyAsXml()
{
    makePages("PageOne", "PageOne.ChildOne", "PageTwo");
    submitRequest("root", "type:pages");
    assertResponseIsXML();
    assertResponseContains("<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>");
}

public function testSymbolicLinksAreNotInXmlPageHierarchy() 
{
    $page = makePage("PageOne");
    makePages("PageOne.ChildOne", "PageTwo");
    addLinkTo($page, "PageTwo", "SymPage");
    submitRequest("root", "type:pages");
    assertResponseIsXML();
    assertResponseContains("<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>");
    assertResponseDoesNotContain("SymPage");
}

public function testGetDataAsXml()
{
    makePageWithContent("TestPageOne", "test page");
    submitRequest("TestPageOne", "type:data");
    assertResponseIsXML();
    assertResponseContains("test page", "<Test");
}

The benefit of this pattern is that the vast majority of annoying details have been eliminated. The tests get right to the point and use only the data types and functions that they truly need. Anyone who reads these tests should be able to understand what they do very quickly, without being misled or overwhelmed by details.

#4 Single Responsibility and Error Handling

The best way to describe this is to quote directly from the book:

Functions should do one thing. Error handing is one thing. Thus, a function that handles errors should do nothing else. This implies that if the keyword try exists in a function, it should be the very first word in the function and that there should be nothing after the catch/finally.

#5 Better Error Handling

how do you think this piece of code can get better shaped?

$port = new ACMEPort(12);
try {
    $port->open();
} catch (DeviceResponseException $e) {
        reportPortError($e);
        logger()->log("Device response exception", $e);
    } catch (ATM1212UnlockedException $e) {
        reportPortError($e);
        logger()->log("Unlock exception", $e);
    } catch (GMXError $e) {
        reportPortError($e);
        logger()->log("Device response exception");
    } finally {
        /// ...
}

We can simplify our code considerably by wrapping the API that we are calling and making sure that it returns a common exception type:

$port = new LocalPort(12);

try {
    $port->open();
} catch (PortDeviceFailure $e) {
    reportError($e);
    logger()->log($e->getMessage(), $e);
} finally {
    // ...
}
class LocalPort {

    private $innerPort;

    public function __construct(int $portNumber) {
        $this->innerPort = new ACMEPort($portNumber);
    }

    public function open() {
        try {
            $this->innerPort->open();
        } catch (DeviceResponseException $e) {
            throw new PortDeviceFailure($e);
        } catch (ATM1212UnlockedException $e) {
            throw new PortDeviceFailure($e);
        } catch (GMXError $e) {
            throw new PortDeviceFailure($e);
        }
    }

    // ...
}

Wrappers like the one we defined for ACMEPort can be very useful.

Okay. This is it for this part. I’ll continue posting the next parts soon. You can join my Telegram channel to get notified of the latest posts. Also, you can follow me on Twitter and LinkedIn.

A Few Words on Webhooks

Mehrad Sadeghi — Mon, 01 Aug 2022 18:58:00 +0000

In 2006 during working on a startup, Jeff Lindsay wrote about an architectural pattern he called “webhooks”. Since then almost all web developers have heard this term.

I think webhooks are mostly based on the Observer design pattern. Observer is a pattern where an observer is observing (looking) for an event to be fired. The important part here is that the observer is not polling anything, It registers itself to the origin to get notified when the desired event happens.
Polling is another method where the destination is checking for new changes in origin constantly, As opposed to what the observer pattern does.

Webhooks are very similar to observers. A webhook is basically an endpoint that should be notified (called) when an event is dispatched. This approach is better than the “Polling” method in most cases. It is faster and uses less resource.

So by webhooks, Applications can use a so-called “hook”, To send automated messages to each other when something (an event) happens. For example, When you buy a product online, You receive an email or an SMS. What happens here is that the email or SMS provider provides an endpoint (in this context a webhook) and the store calls this endpoint when for example an order is placed.

You can learn more about webhooks in this crash course on youtube.

Laravel CRUD Generator

Mehrad Sadeghi — Tue, 22 Sep 2020 15:56:00 +0000

Laravel CRUD Generator is a simple and light-weight wrapper on Laravel's default controller generator, Which makes creating a controller with a pre-defined CRUD like a breeze.

You can define your validation rules in an interactive way that crud-generator provides. Also it is compatible with Laravel 5.x, 6.x, 7.x, 8.x and 9.x.

There is demo available here which is showing how it's done :)

Installation

$ composer require mehradsadeghi/laravel-crud-generator

Usage

It works based on your $fillable property of the target model.

If you would like to use $guarded instead of $fillable, It is supported too. In that case you'll need to have an existing Schema (table), Then the crud generator will automatically figures out your fillables.

As an example:

$ php artisan make:crud UserController --model=User

If you would like to have validaiton rules too, You may enter the --validation option:

$ php artisan make:crud UserController --model=User --validation

Customizing Default Stubs

It is possible to publish default stubs and change them in a way that fulfills your requirements.

In order to do this:

$ php artisan crud:publish

The published stubs will be located within stubs/crud directory in the root of your application. Any changes you make to these stubs will be reflected when you generate crud.

Feel free to take a look at crud-generator repository.

How To Filter Your Eloquent Queries Based on URL Query String in Laravel Like a Pro

Mehrad Sadeghi — Fri, 31 Jul 2020 17:50:00 +0000

Describing the Problem

You have probably faced the situation where you needed to filter your query based on given parameters in url query-string and after developing the logics, You've had a code-base like what we can in the above image.

This approach works, But it's not a good practice.

When the number of parameters starts to grow, The number of these kind of if statements also grows and your code gets huge and hard to maintain.

Also it's against the Open/Closed principal of SOLID principles, Because when you have a new parameter, You need to get into your existing code and add a new logic (which may breaks the existing implementations).

So we have to design a way to make our filters logics separated from each other and apply them into the final query, which is the whole idea behind the package I wrote for Laravel.

Laravel Filter Query String

First you need to install the package:

$ composer require mehradsadeghi/laravel-filter-querystring

Then you should use the FilterQueryString trait in your model, And define $filters property which can be consist of available filters or your custom filters.

use Mehradsadeghi\FilterQueryString\FilterQueryString;

class User extends Model
{
    use FilterQueryString;

    protected $filters = [];

    ...
}

Then you need to use filter() method in your eloquent query. For example:

User::select('name')->filter()->get();

Available Methods

Sort
Comparisons
In
Like
Where clause

For the purpose of explaining each method, Imagine we have such data in our users table:

id	name	email	username	age	created_at
1	mehrad	mehrad@example.com	mehrad123	20	2020-09-01
2	reza	reza@example.com	reza123	20	2020-10-01
3	hossein	hossein@example.com	hossein123	22	2020-11-01
4	dariush	dariush@example.com	dariush123	22	2020-12-01

And assume our query is something like this:

User::filter()->get();

Sort

Sort is the equivalent to order by sql statement which can be used flexible in FilterQueryString:

Conventions:

?sort=field
?sort=field,sort_type
?sort[0]=field1&sort[1]=field2
?sort[0]=field1&sort[1]=field2,sort_type
?sort[0]=field1,sort_type&sort[1]=field2,sort_type

In User.php

protected $filters = ['sort'];

Single sort:

https://example.com?sort=created_at

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01
reza	reza@example.com	reza123	20	2020-10-01
hossein	hossein@example.com	hossein123	22	2020-11-01
dariush	dariush@example.com	dariush123	22	2020-12-01

Note that when you're not defining sort_type, It'll be asc by default.

Multiple sorts:

https://example.com?sort[0]=age,desc&sort[1]=created_at,desc

Output:

name	email	username	age	created_at
dariush	dariush@example.com	dariush123	22	2020-12-01
hossein	hossein@example.com	hossein123	22	2020-11-01
reza	reza@example.com	reza123	20	2020-10-01
mehrad	mehrad@example.com	mehrad123	20	2020-09-01

Comparisons

Comparisons are consist of 6 filters:

greater
greater_or_equal
less
less_or_equal
between
not_between

Conventions:

?greater=field,value
?greater_or_equal=field,value
?less=field,value
?less_or_equal=field,value
?between=field,value1,value2
?not_between=field,value1,value2

In User.php

protected $filters = [
    'greater',
    'greater_or_equal',
    'less',
    'less_or_equal',
    'between',
    'not_between'
];

Example of greater:

https://example.com?greater=age,20

Output:

name	email	username	age	created_at
hossein	hossein@example.com	hossein123	22	2020-11-01
dariush	dariush@example.com	dariush123	22	2020-12-01

Example of not_between:

https://example.com?not_between=age,21,30

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01
reza	reza@example.com	reza123	20	2020-10-01

In

In clause is the equivalent to where in sql statement.

Convention:

?in=field,value1,value2

In User.php

protected $filters = ['in'];

Example:

https://example.com?in=name,mehrad,reza

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01
reza	reza@example.com	reza123	20	2020-10-01

Like

Like clause is the equivalent to like '%value%' sql statement.

Conventions:

?like=field,value
?like[0]=field1,value1&like[1]=field2,value2

In User.php

protected $filters = ['like'];

Single like:

https://example.com?like=name,meh

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01

Multiple likes:

https://example.com?like[0]=name,meh&like[1]=username,dar

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01
dariush	dariush@example.com	dariush123	22	2020-12-01

Where Clause (default filter)

Generally when your query string parameters are not one of previous available methods, It'll get filtered by the default filter which is the where sql statement. It's the proper filter when you need to directly filter one of your table's columns.

Conventions:

?field=value
?field1=value&field2=value
?field1[0]=value1&field1[1]=value2
?field1[0]=value1&field1[1]=value2&field2[0]=value1&field2[1]=value2

Assuming we want to filter name, username and age database columns, In User.php

protected $filters = ['name', 'username', 'age'];

Example:

https://example.com?name=mehrad

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01

Example:

https://example.com?age=22&username=dariush123

Output:

name	email	username	age	created_at
dariush	dariush@example.com	dariush123	22	2020-12-01

Example:

https://example.com?name[0]=mehrad&name[1]=dariush

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01
dariush	dariush@example.com	dariush123	22	2020-12-01

Example:

https://example.com?name[0]=mehrad&name[1]=dariush&username[0]=mehrad123&username[1]=reza1234

Output:

name	email	username	age	created_at
mehrad	mehrad@example.com	mehrad123	20	2020-09-01

Custom Filters

By custom filters you can define your own methods as filters. This helps with the Open/Closed of SOLID principles, Hence each time a new filter is needed, you don't have to edit previous filters and you can just write a separate method for it.

Let's create a custom filter. Assuming you want to create a filter named all_except which retrieves all users except the one that is specified:

In User.php

protected $filters = ['all_except'];

public function all_except($query, $value) {
    $query->where('name', '!=', $value);
}

To test our newly added filter:

https://example.com?all_except=mehrad

Output:

name	email	username	age	created_at
reza	reza@example.com	reza123	20	2020-10-01
hossein	hossein@example.com	hossein123	22	2020-11-01
dariush	dariush@example.com	dariush123	22	2020-12-01

Note that your custom defined filters have the most priority which means you can even override available filters.

For example lets change in filter in a way that only accepts 3 values:

In User.php

protected $filters = ['in'];

public function in($query, $value) {

    $exploded = explode(',', $value);

    if(count($exploded) != 4) {
        // throwing an exception or whatever you like to do
    }

    $field = array_shift($exploded);

    $query->whereIn($field, $exploded);
}

Another good example for custom filters are when you don't want to expose your database table's column name. For example assume we don't want to expose that we have a column named username in users table:

In User.php

protected $filters = ['by'];

public function by($query, $value) {
    $query->where('username', $value);
}

https://example.com?by=dariush123

Output:

name	email	username	age	created_at
dariush	dariush@example.com	dariush123	22	2020-12-01

Minor Tip

In order to prevent your model to get messy or populated with filter methods, You can create a trait for it and put everything about filters inside the trait.

You can also take a look at Laravel Filter Query String GitHub repo.

DEV Community: Mehrad Sadeghi

Circuit Breaker Pattern Explained: How to Prevent Cascading Failures in Distributed Systems

What Is the Circuit Breaker Pattern ?

Why Do Distributed Systems Need Circuit Breakers ?

Reliability, High Availability, and Circuit Breakers

How Does a Circuit Breaker Work ?

CLOSED - Everything Is Normal

OPEN - Stop Calling the Failing Service

HALF-OPEN - Has the Service Recovered ?

Why Does HALF-OPEN Allow Only a Few Requests ?

A Real-World Scenario: Payment Service Failure

What Is a Fallback?

Circuit Breaker ≠ Retry

How Retries Can Cause a Cascading Failure

Exponential Backoff and Jitter

Idempotency: The Problem You Must Consider When Retrying

Important Circuit Breaker Configuration Parameters

Circuit Breaker Has a Cost Too

Where Should the Circuit Breaker Live ?

Do You Always Need a Circuit Breaker ?

Circuit Breaker Alone Is Not Resilience

How Do You Know Your Circuit Breaker Is Working ?

The Goal Isn’t to Eliminate Errors

The State Machine in One Picture

Image by geeksforgeeks

The Bigger Lesson

Final Takeaway

A Final Thought Experiment

Further Reading

MySQL Overselling: Why SELECT Isn't Enough and How SELECT ... FOR UPDATE Solves It

The Naive Implementation

Why Doesn’t REPEATABLE READ Solve This ?

Enter SELECT … FOR UPDATE

Transaction A Gets There First

The Correct Purchase Flow

The Key Idea: Lock Before You Decide

But There’s Another Option

So When Should You Use SELECT … FOR UPDATE ?

A Common Misunderstanding

Don’t Forget the Transaction

What About Deadlocks ?

The Real Lesson

Final Takeaway

Two Transactions, One Row: What Does MySQL Actually Let You See ?

Why Do We Need Transactions ?

What Is a Transaction Isolation Level ?

1. READ UNCOMMITTED - When Uncommitted Data Becomes Visible

Why is this dangerous ?

2. READ COMMITTED - Only See What Has Been Committed

When is READ COMMITTED useful ?

3. REPEATABLE READ - Your Transaction Gets a Snapshot

4. SERIALIZABLE - Make Concurrency Behave More Like Sequential Execution

The Bigger Lesson

The Question You Should Ask

Final Takeaway

Clean Code Made Simple - Part 3

Clean Code Made Simple - Part 2

Clean Code Made Simple - Part 1

A Few Words on Webhooks

Laravel CRUD Generator

Installation

Usage

Customizing Default Stubs

How To Filter Your Eloquent Queries Based on URL Query String in Laravel Like a Pro

Describing the Problem

Laravel Filter Query String

Available Methods

Sort

Comparisons

In

Like

Where Clause (default filter)

Custom Filters

Minor Tip