Imagine two users editing the same record at almost the exact same time.<\/p>\n\n\n\n
Both users click Save<\/strong>. Both API requests return 200 OK<\/strong>. Everything appears to work correctly.<\/p>\n\n\n\n But there is a problem.<\/p>\n\n\n\n One user’s changes may overwrite the other user’s changes.<\/p>\n\n\n\n This is a common concurrency problem<\/strong> in modern applications. It can lead to lost updates, incorrect data, and unexpected results.<\/p>\n\n\n\n Understanding concurrency is important when building reliable APIs and database systems.<\/p>\n\n\n\n Consider an e-commerce application where two administrators are editing the same product.<\/p>\n\n\n\n The database initially contains:<\/p>\n\n\n\n Laptop \u2014 \u20b950,000<\/strong><\/p>\n\n\n\n Both administrators open the product at the same time.<\/p>\n\n\n\n Admin A changes the price to:<\/p>\n\n\n\n \u20b948,000<\/strong><\/p>\n\n\n\n Admin B changes the price to:<\/p>\n\n\n\n \u20b949,000<\/strong><\/p>\n\n\n\n Both administrators click Save<\/strong>.<\/p>\n\n\n\n If the application simply processes both update requests, the request that reaches the database last may overwrite the earlier update.<\/p>\n\n\n\n The final price could become:<\/p>\n\n\n\n \u20b949,000<\/strong><\/p>\n\n\n\n Admin A’s update has now disappeared.<\/p>\n\n\n\n This is called a lost update<\/strong>.<\/p>\n\n\n\n The application accepted both requests, but one user’s change was silently overwritten.<\/p>\n\n\n\n Modern applications handle many requests at the same time.<\/p>\n\n\n\n A simplified request flow looks like this:<\/p>\n\n\n\n User \u2192 Frontend \u2192 API \u2192 Database<\/strong><\/p>\n\n\n\n Now imagine two users sending requests almost simultaneously.<\/p>\n\n\n\n Both users may read the same original value before either update reaches the database.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Admin A changes the price to \u20b948,000.<\/p>\n\n\n\n Admin B changes the price to \u20b949,000.<\/p>\n\n\n\n If there is no concurrency control, the last update can overwrite the first one.<\/p>\n\n\n\n The database is not necessarily doing anything wrong.<\/p>\n\n\n\n The real problem is that the application has not defined how concurrent updates should be handled.<\/p>\n\n\n\n This situation is commonly known as a race condition<\/strong>.<\/p>\n\n\n\n A race condition occurs when the result of an operation depends on the timing or order of multiple requests.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n If both requests use the same old data, the second update may overwrite the first one.<\/p>\n\n\n\n The result can therefore depend on which request reaches the database first or last.<\/p>\n\n\n\n That makes the behavior difficult to predict.<\/p>\n\n\n\n One important tool for handling database operations is a transaction<\/strong>.<\/p>\n\n\n\n A transaction groups multiple database operations into one logical unit.<\/p>\n\n\n\n Consider an e-commerce application selling the last available product.<\/p>\n\n\n\n The application may need to:<\/p>\n\n\n\n These operations should work together.<\/p>\n\n\n\n A simplified transaction looks like this:<\/p>\n\n\n\n If something goes wrong, the application can roll back the transaction:<\/p>\n\n\n\n This means the related changes are undone instead of leaving the database in an incomplete state.<\/p>\n\n\n\n However, transactions alone do not automatically solve every concurrency problem.<\/p>\n\n\n\n When multiple requests modify the same record, the application may also need locking, optimistic concurrency, or database constraints<\/strong>.<\/p>\n\n\n\n Pessimistic locking takes a simple approach:<\/p>\n\n\n\n Lock the record before modifying it.<\/p>\n<\/blockquote>\n\n\n\n The idea is that if one transaction is already working with a record, another transaction should wait before making a conflicting change.<\/p>\n\n\n\n For example, Laravel provides Here, the application starts a transaction and locks the selected database row.<\/p>\n\n\n\n Conceptually, the process looks like this:<\/p>\n\n\n\n While User A holds the lock, User B may have to wait before performing a conflicting operation.<\/p>\n\n\n\n This approach can be useful when data must be updated safely and immediately.<\/p>\n\n\n\n Common examples include:<\/p>\n\n\n\n Pessimistic locking is not always the best solution.<\/p>\n\n\n\n Another approach is optimistic locking<\/strong>.<\/p>\n\n\n\n Instead of locking the record immediately, the application checks whether the record changed after it was read.<\/p>\n\n\n\n For example, suppose the product contains:<\/p>\n\n\n\n Both administrators read version 3.<\/p>\n\n\n\n Admin A changes the price:<\/p>\n\n\n\n Admin B still has the old version:<\/p>\n\n\n\n When Admin B tries to save the changes, the application checks the version.<\/p>\n\n\n\n It sees that the database is already on version 4.<\/p>\n\n\n\n The application can reject the update instead of silently overwriting Admin A’s changes.<\/p>\n\n\n\n For example, the API could return:<\/p>\n\n\n\n The frontend can then tell Admin B that the record has changed.<\/p>\n\n\n\n The user can refresh the record, review the latest data, and decide whether to make the change again.<\/p>\n\n\n\n A common implementation uses a version column.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n The update query can check the version before changing the record.<\/p>\n\n\n\n Conceptually:<\/p>\n\n\n\n If another user has already changed the record, the version is no longer 3.<\/p>\n\n\n\n The update therefore affects zero rows.<\/p>\n\n\n\n The application can detect this and return a conflict response.<\/p>\n\n\n\n This prevents silent data loss.<\/p>\n\n\n\n Optimistic locking works especially well when conflicts are relatively uncommon.<\/p>\n\n\n\n Both approaches solve concurrency problems, but they work differently.<\/p>\n\n\n\n The right approach depends on the type of operation and the expected level of contention.<\/p>\n\n\n\n Concurrency problems are not limited to e-commerce applications.<\/p>\n\n\n\n They can appear in many systems.<\/p>\n\n\n\n Suppose only one product remains in stock.<\/p>\n\n\n\n Two customers try to purchase it at the same time.<\/p>\n\n\n\n Without proper concurrency control, both orders could potentially succeed.<\/p>\n\n\n\n The inventory could then become incorrect.<\/p>\n\n\n\n Imagine a cinema with one remaining seat.<\/p>\n\n\n\n Two users select the same seat.<\/p>\n\n\n\n Both requests reach the server at nearly the same time.<\/p>\n\n\n\n The application needs a reliable way to ensure that only one user gets the seat.<\/p>\n\n\n\n Banking systems must carefully handle simultaneous transactions.<\/p>\n\n\n\n Two operations could attempt to modify the same account balance.<\/p>\n\n\n\n Incorrect concurrency handling could result in an inaccurate balance.<\/p>\n\n\n\n An order may be updated by several services.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n If multiple processes update the same order at the same time, the application must prevent inconsistent states.<\/p>\n\n\n\n Two administrators may edit the same configuration.<\/p>\n\n\n\n Without conflict detection, one administrator could unknowingly overwrite the other’s changes.<\/p>\n\n\n\n Document editors and other collaborative systems can have many users modifying the same data.<\/p>\n\n\n\n These systems need more advanced concurrency strategies to decide how simultaneous changes should be handled.<\/p>\n\n\n\n Consider an application that shows:<\/p>\n\n\n\n Two users see the same value.<\/p>\n\n\n\n Both click Buy<\/strong>.<\/p>\n\n\n\n The frontend might perform a simple check:<\/p>\n\n\n\n The problem is that frontend data can become stale.<\/p>\n\n\n\n Both users may see:<\/p>\n\n\n\n But the first purchase could complete before the second request reaches the backend.<\/p>\n\n\n\n The second user’s frontend still thinks one item is available.<\/p>\n\n\n\n This is why critical business rules cannot depend only on frontend validation.<\/p>\n\n\n\n Frontend validation is useful for improving the user experience.<\/p>\n\n\n\n However, the backend and database must ultimately protect the data.<\/p>\n\n\n\n A reliable application should enforce important rules on the server side.<\/p>\n\n\n\n Depending on the use case, this can involve:<\/p>\n\n\n\n The frontend should provide useful feedback.<\/p>\n\n\n\n The backend should enforce the actual business rules.<\/p>\n\n\n\n The database should help maintain data integrity.<\/p>\n\n\n\n Concurrency becomes even more important when requests can be retried.<\/p>\n\n\n\n Imagine a user clicks Save<\/strong>.<\/p>\n\n\n\n The request reaches the server successfully.<\/p>\n\n\n\n However, the network connection fails before the frontend receives the response.<\/p>\n\n\n\n The frontend may assume the request failed and send it again.<\/p>\n\n\n\n Now the same operation may be processed twice.<\/p>\n\n\n\n This is why production systems also need to think about idempotency<\/strong>.<\/p>\n\n\n\n For operations such as payments and order creation, the application may use an idempotency key.<\/p>\n\n\n\n This helps ensure that retrying the same request does not accidentally create duplicate operations.<\/p>\n\n\n\n Testing with one user is not enough for production systems.<\/p>\n\n\n\n An API may work perfectly when one person updates a record.<\/p>\n\n\n\n But what happens when 100 requests arrive at almost the same time?<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This is where concurrency testing becomes important.<\/p>\n\n\n\n Developers should test how the application behaves when multiple requests compete for the same resource.<\/p>\n\n\n\n When building an update API, do not only ask:<\/p>\n\n\n\n “Does the update work?”<\/strong><\/p>\n\n\n\n Also ask:<\/p>\n\n\n\n These questions help uncover problems that normal functional testing may not reveal.<\/p>\n\n\n\n In development, it is easy to focus on whether an API performs the expected operation.<\/p>\n\n\n\n Production systems require a broader perspective.<\/p>\n\n\n\n Developers must also consider timing, failures, retries, concurrent requests, and data consistency.<\/p>\n\n\n\n A good backend design should answer an important question:<\/p>\n\n\n\n What happens when multiple operations try to change the same data at the same time?<\/strong><\/p>\n\n\n\n There should be a clear answer before the application reaches production.<\/p>\n\n\n\n There is no single solution for every application.<\/p>\n\n\n\n The right strategy depends on the operation.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Use transactions<\/strong> when multiple database operations must succeed or fail together.<\/p>\n\n\n\n Use pessimistic locking<\/strong> when conflicting updates are likely and the operation must be protected while it runs.<\/p>\n\n\n\n Use optimistic locking<\/strong> when conflicts are less common but silent overwrites must be prevented.<\/p>\n\n\n\n Use database constraints<\/strong> when the database itself should prevent invalid states.<\/p>\n\n\n\n Use idempotency<\/strong> when requests may be retried and duplicate processing must be avoided.<\/p>\n\n\n\n In many production systems, these techniques work together.<\/p>\n\n\n\n Concurrency is not an unusual edge case.<\/p>\n\n\n\n It is a normal part of modern applications.<\/p>\n\n\n\n Whenever multiple users, API requests, or background jobs can modify the same data, the application needs a clear concurrency strategy.<\/p>\n\n\n\n A reliable system may use:<\/p>\n\n\n\n Transactions + Locking + Optimistic Concurrency + Database Constraints + Idempotency<\/strong><\/p>\n\n\n\n The goal is not to prevent users from working at the same time.<\/p>\n\n\n\n The goal is to make sure their simultaneous actions do not silently produce incorrect data.<\/p>\n\n\n\n So, the next time you build an update API, do not stop at:<\/p>\n\n\n\n “Does this endpoint work?”<\/strong><\/p>\n\n\n\n Ask a more important question:<\/p>\n\n\n\n “What happens when two users update the same record at the same time?”<\/strong><\/p>\n\n\n\n That question is often the starting point for building reliable backend systems.<\/p>","protected":false},"excerpt":{"rendered":" Imagine two users editing the same record at almost the exact same time. Both users click Save. Both API requests return 200 OK. Everything appears to work correctly. But there is a problem. One user’s changes may overwrite the other user’s changes. This is a common concurrency problem in modern applications. It can lead to […]<\/p>\n","protected":false},"author":2,"featured_media":6404,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6403","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"yoast_head":"\nA Simple Example of a Concurrency Problem<\/h2>\n\n\n\n
Why Does a Lost Update Happen?<\/h2>\n\n\n\n
User A \u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u251c\u2500\u2500> API \u2500\u2500> Database\nUser B \u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/code><\/pre>\n\n\n\nInitial price: \u20b950,000\n\nAdmin A reads: \u20b950,000\nAdmin B reads: \u20b950,000<\/code><\/pre>\n\n\n\nWhat Is a Race Condition?<\/h2>\n\n\n\n
Request A reads data\nRequest B reads data\n\nRequest A updates data\nRequest B updates data<\/code><\/pre>\n\n\n\nTransactions: The First Layer of Protection<\/h2>\n\n\n\n
\n
BEGIN TRANSACTION\n\nCheck stock\nDecrease stock\nCreate order\n\nCOMMIT<\/code><\/pre>\n\n\n\nROLLBACK<\/code><\/pre>\n\n\n\nPessimistic Locking<\/h2>\n\n\n\n
\n
lockForUpdate()<\/code> for this type of operation.<\/p>\n\n\n\nDB::transaction(function () {\n $product = Product::where('id', 1)\n ->lockForUpdate()\n ->first();\n\n $product->price = 48000;\n $product->save();\n});<\/code><\/pre>\n\n\n\nUser A\n \u2193\nLock Row\n \u2193\nUpdate Row\n \u2193\nCommit\n \u2193\nRelease Lock\n\nUser B\n \u2193\nWait\n \u2193\nContinue<\/code><\/pre>\n\n\n\n\n
Optimistic Locking<\/h2>\n\n\n\n
Product: Laptop\nPrice: \u20b950,000\nVersion: 3<\/code><\/pre>\n\n\n\nPrice: \u20b948,000\nVersion: 4<\/code><\/pre>\n\n\n\nVersion: 3<\/code><\/pre>\n\n\n\n409 Conflict<\/code><\/pre>\n\n\n\nHow Does Optimistic Locking Work?<\/h2>\n\n\n\n
id | price | version\n1 | 50000 | 3<\/code><\/pre>\n\n\n\nUPDATE products\nSET price = 49000,\n version = 4\nWHERE id = 1\n AND version = 3;<\/code><\/pre>\n\n\n\nPessimistic vs. Optimistic Locking<\/h2>\n\n\n\n
Approach<\/th> How It Works<\/th> Best For<\/th><\/tr> Pessimistic Locking<\/td> Locks the record during the transaction<\/td> High-conflict operations<\/td><\/tr> Optimistic Locking<\/td> Detects changes before saving<\/td> Occasional conflicts<\/td><\/tr> Transactions<\/td> Groups related operations together<\/td> Maintaining data consistency<\/td><\/tr> Database Constraints<\/td> Prevents invalid data states<\/td> Enforcing business rules<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Where Does Concurrency Matter in Real Applications?<\/h2>\n\n\n\n
Inventory<\/h3>\n\n\n\n
Seat Booking<\/h3>\n\n\n\n
Banking<\/h3>\n\n\n\n
Order Processing<\/h3>\n\n\n\n
Payment Service\n \u2193\nOrder Service\n \u2193\nShipping Service\n \u2193\nNotification Service<\/code><\/pre>\n\n\n\nAdmin Dashboards<\/h3>\n\n\n\n
Collaborative Applications<\/h3>\n\n\n\n
Why Frontend Validation Is Not Enough<\/h2>\n\n\n\n
Stock: 1<\/code><\/pre>\n\n\n\nif (stock > 0) {\n purchase();\n}<\/code><\/pre>\n\n\n\nStock: 1<\/code><\/pre>\n\n\n\nBackend and Database Controls Matter<\/h2>\n\n\n\n
\n
What About API Retries?<\/h2>\n\n\n\n
What Happens When 100 Requests Arrive at Once?<\/h2>\n\n\n\n
Request 1 \u2500\u2500\u2510\nRequest 2 \u2500\u2500\u2524\nRequest 3 \u2500\u2500\u2524\nRequest 4 \u2500\u2500\u2524\n ... \u251c\u2500\u2500> API \u2500\u2500> Database\nRequest 99 \u2500\u2500\u2524\nRequest 100 \u2500\u2518<\/code><\/pre>\n\n\n\nQuestions Developers Should Ask<\/h2>\n\n\n\n
\n
The Production Mindset<\/h2>\n\n\n\n
Choosing the Right Concurrency Strategy<\/h2>\n\n\n\n
The Key Takeaway<\/h2>\n\n\n\n