The third part of our series was about If-Match and how you can use it to prevent lost updates for PUT and PATCH - two clients process the same resource, the server detects the collision based on the ETag and rejects the stale write access. One question remained unanswered: What about POST? When …

The second part of our series was about caching headers - and in the pro tip about strong vs. weak ETags we briefly teased that strong ETags have a second job: They protect you from lost updates when writing. That’s exactly what today is about.

After understanding the architecture, eliminating performance killers and taming dangerous config defaults in this series, today we come to perhaps the most important question: How do I actually get there?