6 ms·
> Do you think the issue was something else? No, I'm not questioning whether or not it was a caching issue. I'm taking exception to the lack of accountability.
by twisteriffic 3y ago
> Do you think the issue was something else?
No, I'm not questioning whether or not it was a caching issue. I'm taking exception to the lack of accountability. They chose the library. They (probably) chose to ignore a documented or common failure mode of caching systems through either poor choice of key or lack of synchronization. They've obviously designed their infrastructure in a way that isn't resilient to its current level of usage (cold start is a normal part of software's lifecycle).
They could have chosen to own that, but instead they blamed everyone else. That's not a sign of a trustworthy service provider.
- quatrefoil 3y agoIt's not even that: the quoted language doesn't even blame the library - it appears to blame increased load. "As a result of increased demand, it mixed up device ID" - no, it mixed up IDs as a result of some sort of a concurrency bug. I don't understand the point of deflecting this far.
- matthewcford 3y agoLikely to be a multi-threading issue; my bet is the cache client wasn't thread-safe. I've seen this in some apps before and the solution was to turn off multi-threading while we debug the library that was causing the issue.
- sabujp 3y agoThis is the answer!
- NegativeK 3y ago> I'm taking exception to the lack of accountability. I'll bet money that their statement was run through legal and stripped of all possible blamey statements. > They could have chosen to own that, but instead they blamed everyone else. That's not a sign of a trustworthy service provider. I agree. Companies need to own up to their fuckups, even with legal tells them that it can hurt. Because all companies will fuck up; how they handle it is the differentiator.