I have control of two systems, let's call them proxy and store, and access to to a third-party system, let's call it producer.
+----------+ +-------+ +-------+
| producer | -> | proxy | -> | store |
+----------+ +-------+ +-------+
The producer produces messages that become records in the store, via the proxy consuming those messages and sending them to the store with HTTP requests. The concurrency issue I'm running into is that the messages are produced quickly enough that a message for updating a record may reach the store before the message creating the record does.
My Question
I've worked around this with a simple timeout on the proxy before sending any PATCH requests. It works, as far as it goes, but I know it's a hack with some real flaws.
My question is, how else should I be thinking about this? What are some more idiomatic (or even canonical) ways to approach this. I'm using Node on both proxy and store, with MySQL behind the store. Currently (operative word), there is no access to a key/value store like Redis.
The solutions that seem to make sense are: (A) Implement some sort of lock, and (B) Make all db inputs an INSERT ... ON DUPLICATE KEY UPDATE query. For (A), I'm not sure where the lock should happen – on the proxy, or on the store? For (B), this seems to kind of break the semantics of HTTP methods.
Any input on these (or a completely different strategy) is much appreciated.
