title: MongoDB / Redis / SQL concurrency pattern: read-modify-write by multiple processes
body: <p>Relatively DB newbie here.</p>
  
  <p>So I'm facing a recurring problem that multiple processes attempts Read-Modify-Write operations to the same DB instance, be it MongoDB, Redis, or SQL.</p>
  
  <p>In Redis, one solution is to leverage the atomicity of the Redis Lua scripting to guarantee atomicity, but may result moving a considerable amount of application logic onto Redis. (whether good or bad?)</p>
  
  <p>In SQL, it seems there are atomic stored procedures that achieves similar results, but also risking moving too much application logic into the DB itself (whether good or bad?)</p>
  
  <p>MongoDB doesn't even really have a concept of internal scripting (the javascript solution seems to be deprecated)</p>
  
  <p>Then in the general sense, as implied above, it might be good (?) to keep the application logic <em>outside</em> of the data store to achieve maximum application logic distribution and scalability across multiple nodes of services.</p>
  
  <p>But making application logic distributed across multiple processes (nodes) and have them concurrently access the shared data store warrants the read-modify-write cycle to be guarded from possible race conditions.</p>
  
  <p>So my questions are: </p>
  
  <ol>
  <li>for Redis or SQL, should I abuse the provided atomic scripting support to totally avoid any possible race, but putting more and more application logic into the data store, or</li>
  <li>is the read-modify-write model more common for the majority of the DB concurrency access, and if yes, are there some "standard" guidelines about how to synchronize the concurrent read-modify-write from multiple processes?</li>
  </ol>
  
  <p>Thank!</p>