Vengala Vinay

Having 12+ Years of Experience in Software Development

Home » How We Audited a High-Traffic Laravel Enterprise Stack on AWS and Mitigated Race conditions during high-concurrency payment processing

How We Audited a High-Traffic Laravel Enterprise Stack on AWS and Mitigated Race conditions during high-concurrency payment processing

Initial Stack Assessment and Bottleneck Identification

Our engagement began with a deep dive into a high-traffic Laravel application hosted on AWS, specifically focusing on its payment processing module. The primary concern was intermittent failures and data inconsistencies observed during peak load, strongly suggesting race conditions. The existing infrastructure comprised a multi-AZ RDS Aurora PostgreSQL cluster, ElastiCache Redis for caching and session management, and a fleet of EC2 instances running the Laravel application behind an Application Load Balancer (ALB). A critical observation was the lack of explicit locking mechanisms around the financial transaction logic.

Deep Dive into Payment Processing Logic

The core of the issue lay within the `process_payment` method, which handled debiting user balances and crediting merchant accounts. A simplified, albeit vulnerable, representation of this logic is shown below:

// app/Services/PaymentService.php (Simplified & Vulnerable)

public function processPayment(User $user, Order $order, float $amount): bool
{
    // 1. Check user balance
    if ($user->balance < $amount) {
        throw new InsufficientFundsException("Insufficient balance.");
    }

    // 2. Debit user balance
    $user->balance -= $amount;
    $user->save();

    // 3. Credit merchant account (simplified)
    $merchant = $order->merchant;
    $merchant->balance += $amount;
    $merchant->save();

    // 4. Record transaction
    Transaction::create([
        'user_id' => $user->id,
        'order_id' => $order->id,
        'amount' => $amount,
        'status' => 'completed',
    ]);

    return true;
}

The race condition arises because multiple concurrent requests could execute steps 1 and 2 independently. Imagine two requests for the same user, each attempting to process a payment of $100, and the user has a balance of $150. Both requests might pass the balance check (step 1) simultaneously. Then, both might proceed to debit the balance (step 2), resulting in the user’s balance being debited twice ($150 – $100 – $100 = -$50), which is incorrect. The `save()` operations are not atomic with the balance check, and there’s no mechanism to prevent a read-modify-write cycle from being interrupted by another concurrent transaction.

Leveraging Database-Level Locking for Atomicity

The most robust solution for ensuring atomicity in financial transactions is to leverage database-level locking. For PostgreSQL, the `SELECT … FOR UPDATE` clause is ideal. This locks the selected rows until the end of the current transaction, preventing other transactions from reading or modifying them. We modified the `PaymentService` to incorporate this.

Refactoring with `SELECT … FOR UPDATE`

The refactored code first retrieves the user record within a database transaction and immediately locks it using `for_update()`. This ensures that no other process can modify the user’s balance while our transaction is active.

// app/Services/PaymentService.php (Refactored with Locking)

use Illuminate\Support\Facades\DB;
use App\Exceptions\InsufficientFundsException;

public function processPayment(User $user, Order $order, float $amount): bool
{
    DB::beginTransaction();

    try {
        // 1. Retrieve user and lock the row for the duration of the transaction
        // We re-fetch the user within the transaction to ensure we get the locked row.
        $lockedUser = User::where('id', $user->id)->lockForUpdate()->first();

        if (!$lockedUser) {
            DB::rollBack();
            throw new \Exception("User not found during transaction.");
        }

        // 2. Check user balance (now safe due to locking)
        if ($lockedUser->balance < $amount) {
            DB::rollBack();
            throw new InsufficientFundsException("Insufficient balance.");
        }

        // 3. Debit user balance
        $lockedUser->balance -= $amount;
        $lockedUser->save(); // This save operates on the locked record

        // 4. Credit merchant account (simplified)
        // For simplicity, assuming merchant lookup and update is less critical for race conditions
        // or is handled with its own locking if necessary. In a real system, this would also
        // need careful consideration, potentially with its own FOR UPDATE lock.
        $merchant = $order->merchant;
        $merchant->balance += $amount;
        $merchant->save();

        // 5. Record transaction
        Transaction::create([
            'user_id' => $lockedUser->id,
            'order_id' => $order->id,
            'amount' => $amount,
            'status' => 'completed',
        ]);

        DB::commit();
        return true;

    } catch (\Exception $e) {
        DB::rollBack();
        // Log the error appropriately
        Log::error("Payment processing failed: " . $e->getMessage(), ['user_id' => $user->id, 'order_id' => $order->id]);
        throw $e; // Re-throw to allow calling code to handle
    }
}

Crucially, the `DB::beginTransaction()` and `DB::commit()` / `DB::rollBack()` calls wrap the entire critical section. If any part of the operation fails (e.g., insufficient funds, database error), the transaction is rolled back, ensuring data consistency. The `lockForUpdate()` method in Eloquent translates directly to `SELECT … FOR UPDATE` in SQL.

Optimizing Database Performance with Indexes

While locking prevents race conditions, it can introduce contention under very high concurrency. To mitigate potential performance degradation, we reviewed and optimized database indexes. The primary table involved in the critical path was the `users` table. We ensured that the primary key (`id`) was indexed (which is standard) and added an index on `users.balance` if it wasn’t already present, although `FOR UPDATE` primarily locks the row identified by the primary key or unique constraints. More importantly, for queries that might precede the `lockForUpdate` call (e.g., fetching orders), ensuring appropriate indexes exist on foreign keys and columns used in `WHERE` clauses is vital.

-- Example SQL for checking/adding indexes (PostgreSQL)

-- Check existing indexes on users table
SELECT
    tablename,
    indexname,
    indexdef
FROM
    pg_indexes
WHERE
    tablename = 'users';

-- If balance is frequently queried and updated, an index might be considered,
-- though FOR UPDATE on PK is the primary mechanism for this race condition.
-- CREATE INDEX IF NOT EXISTS users_balance_idx ON users (balance);

-- Ensure foreign keys are indexed (e.g., for order lookups)
-- CREATE INDEX IF NOT EXISTS orders_user_id_idx ON orders (user_id);

The `lockForUpdate()` operation itself doesn’t require an index on the `balance` column; it locks the row identified by the primary key (`users.id`). However, efficient retrieval of the user record (e.g., `User::where(‘id’, $user->id)`) relies on the primary key index. If the initial lookup involved other criteria, those would need indexing.

Configuration Tuning for High Concurrency

Beyond code changes, infrastructure configuration plays a crucial role. We reviewed the following AWS and application configurations:

  • RDS Aurora PostgreSQL `max_connections`: Increased to accommodate the potential for more active transactions, balancing against memory usage.
  • RDS Aurora `innodb_buffer_pool_size` (if using MySQL-compatible) or equivalent for PostgreSQL: Tuned to maximize cache hit ratio for frequently accessed data.
  • ElastiCache Redis configuration: Ensured sufficient memory and appropriate eviction policies. While not directly involved in the locking mechanism, Redis performance impacts overall request latency.
  • EC2 Auto Scaling Group: Adjusted scaling policies to react more aggressively to CPU utilization spikes, ensuring enough application instances are available to handle incoming requests without excessive queuing.
  • ALB Health Checks: Verified health check intervals and thresholds were optimized to quickly remove unhealthy instances without dropping legitimate traffic.

Example RDS PostgreSQL Parameter Group Tuning

A common parameter to adjust for high-concurrency workloads on PostgreSQL is `max_connections`. The optimal value depends heavily on instance size and available RAM. A starting point might be to set it based on available memory, leaving ample room for the OS and other processes.

# Example PostgreSQL Parameter Group Settings (via AWS RDS Console/CLI)

# Adjust based on instance RAM. For a db.r5.2xlarge (61 GiB RAM),
# leaving ~10-15 GiB for OS/other processes, ~45-50 GiB for PostgreSQL.
# Each connection typically consumes ~1-2MB + query-specific memory.
# A value like 2000-3000 might be a reasonable starting point.
max_connections = 2500

# Ensure sufficient shared buffers for caching. Typically 25% of instance RAM.
shared_buffers = 15GB

# Tune work_mem for complex queries if identified during performance testing.
# Be cautious as this is per-operation memory.
# work_mem = 64MB

Monitoring and Validation

Post-implementation, rigorous monitoring was essential. We employed:

  • AWS CloudWatch Metrics: Monitored RDS CPU utilization, connection counts, transaction rates, and latency. EC2 CPU utilization, network I/O, and ALB request counts/latency were also key.
  • Application Performance Monitoring (APM) Tools: Utilized tools like New Relic or Datadog to trace individual payment transactions, identify slow database queries, and pinpoint errors.
  • PostgreSQL `pg_stat_activity`: Regularly queried `pg_stat_activity` to observe active transactions, identify long-running queries, and detect potential deadlocks or lock contention.
  • Load Testing: Simulated high-concurrency scenarios using tools like k6 or JMeter to validate the fix under stress and measure performance improvements.

Querying `pg_stat_activity` for Lock Information

During testing and post-deployment, this query proved invaluable for diagnosing lock-related issues:

SELECT
    pid,
    usename,
    datname,
    client_addr,
    state,
    wait_event_type,
    wait_event,
    query
FROM
    pg_stat_activity
WHERE
    wait_event_type = 'Lock' OR state = 'active';

This query helps identify processes that are waiting for locks (`wait_event_type = ‘Lock’`) or are currently executing long-running queries (`state = ‘active’`). Correlating PIDs across different `pg_stat_activity` entries can reveal blocking relationships.

Conclusion

By systematically analyzing the application code, identifying the critical race condition in payment processing, and implementing robust database-level locking with `SELECT … FOR UPDATE`, we successfully mitigated the intermittent failures. Complementary optimizations in database indexing and infrastructure tuning ensured the solution scaled effectively under high load. Continuous monitoring and load testing validated the fix, providing confidence in the stability and integrity of the payment processing system.

Recent Posts

Top Categories

Our Products

Our Services