Not sure where you’re getting that definition from my post, I certainly don’t mean to imply that. As given, my definition (“a description for an operation that — when applied multiple times — will behave the same as if it was applied once”) means to indicate that applying the operation multiple times will result in the same underlying behavior (that is, of the state of the system) despite multiple applications. I’m not saying that the response should be the same value each time as you imply. As for the notify_friends example where the check is propagated back to the caller, I don’t mean to indicate that the system is no longer idempotent. It is, but it is also rather fragile. It’s not idempotent when dealing with a system with multiple callers, and it doesn’t help when knowing if the notification service received receipt of the request.
As for your other concern, RDBMS’s are certainly solid choices for certain use cases. What I meant by “really quick on reads and writes” was respective to request load, although I should have clarified this. Single-machine RDBMS solutions’ performance will degrade as the number of connections increases, and in the past I’ve had issues with this that could have been more easily solved by a distributed solution. Cassandra’s tunable consistency solves this quite well, a feature you’ve pointed out in your response.