[twisteriffic]

> 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]

It'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]

Likely 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]

This is the answer!

[NegativeK]

> 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.