Concurrent order/inventory system

 

Interview answer

This is one of the most important real-world Laravel/MySQL concurrency scenarios.

Suppose inventory is:

stock = 1

Two customers simultaneously try to purchase the final item.

A naive implementation:

$product = Product::find($id);

if ($product->stock > 0) {
    $product->stock--;
    $product->save();
}

can suffer from a race condition because both requests may read stock = 1.

Safer approach

Use a transaction and row locking:

DB::transaction(function () use ($productId) {

    $product = Product::whereKey($productId)
        ->lockForUpdate()
        ->firstOrFail();

    if ($product->stock < 1) {
        throw new RuntimeException('Out of stock');
    }

    $product->decrement('stock');

    Order::create([
        'product_id' => $product->id,
        'quantity' => 1,
    ]);
});

lockForUpdate() locks the selected row until the transaction completes.

Conceptually:

Request A                         Request B

BEGIN                             BEGIN
   ↓                                ↓
lock product                       waits
   ↓
stock = 1
   ↓
decrement → 0
   ↓
COMMIT
                                  gets lock
                                     ↓
                                  stock = 0
                                     ↓
                                  reject order

Production considerations

For a real e-commerce system, I would also consider:

• database transaction boundaries

• row-level locking

• appropriate indexes

• deadlock handling/retries

• idempotency for payment/order requests

• order state transitions

• inventory reservation versus immediate decrement

• payment failures and compensation

• unique constraints for duplicate order/payment requests

• queue-based processing where appropriate

For example, an inventory reservation might use:

available_stock
reserved_stock

rather than immediately treating every checkout attempt as a completed sale.

Read More

Pagination strategies in laravel

 Laravel provides normal pagination:

$users = User::paginate(20);

This provides page metadata such as:

current_page
last_page
total
per_page

simplePaginate() avoids the total-count query:

User::simplePaginate(20);

For very large datasets, cursor pagination can be more efficient:

User::orderBy('id')->cursorPaginate(20);

Scenario

For an admin dashboard with 5,000 users, standard pagination may be perfectly reasonable.

For an API serving millions of records and clients repeatedly requesting the next page, cursor pagination can avoid expensive large OFFSET operations.

A stable, indexed ordering column is important for cursor pagination.

Read More

Optimizing slow Eloquent queries in Laravel

 My debugging process would be:

1. Identify the slow endpoint/query.

2. Inspect generated SQL.

3. Check for N+1.

4. Use eager loading where appropriate.

5. Select only required columns.

6. Add appropriate indexes.

7. Use EXPLAIN.

8. Check unnecessary relationships and joins.

9. Paginate large datasets.

10. Measure again.

Instead of:

$users = User::with('orders')->get();

if I only need names:

$users = User::select('id', 'name')->get();

For counts:

$users = User::withCount('orders')->get();

For existence:

$users = User::whereHas('orders')->get();

Scenario

If an API suddenly becomes slow after the database grows from 10,000 to 10 million orders, I wouldn't immediately add caching. I'd first inspect query plans, indexes, query volume, returned rows, and N+1 behavior.

Read More

MySQL indexes Laravel

 Indexes improve lookup performance by allowing MySQL to locate rows more efficiently.

Example:

$table->index('email');
$table->index(['user_id', 'status']);

A composite index:

INDEX(user_id, status)

can be useful for:

WHERE user_id = ?
AND status = ?

Important interview point

Indexes aren't free.

They:

• consume storage

• increase write/update cost

• require maintenance

• can be useless if poorly designed

I verify indexing decisions using:

EXPLAIN SELECT ...

For example:

EXPLAIN
SELECT *
FROM orders
WHERE user_id = 10
AND status = 'paid';

I would inspect the execution plan rather than adding indexes blindly.

Read More