Did you have to limit the number of likes from users? (e.g. each user is only allowed to 'like' once.)
Also, am I right in thinking that only having Increment and Decrement commands safeguards the data against concurrency issues (where one update might be 'lost' due to another overwriting it)?
Should be fine with concurrency... You'll still want a separate likes table for post-like and probably a user-like that references the posts liked by a user.
Scylla/Cassandra is not atomic across tables... And query performance isn't always great. So sometimes you'll want your own 1:n mappings both ways.
Sounds like an interesting approach.
Did you have to limit the number of likes from users? (e.g. each user is only allowed to 'like' once.)
Also, am I right in thinking that only having Increment and Decrement commands safeguards the data against concurrency issues (where one update might be 'lost' due to another overwriting it)?
Should be fine with concurrency... You'll still want a separate likes table for post-like and probably a user-like that references the posts liked by a user.
Scylla/Cassandra is not atomic across tables... And query performance isn't always great. So sometimes you'll want your own 1:n mappings both ways.
Ah, great idea - with the user-like table, you'd also be able to see how many times a user has 'liked' a post (if that was a requirement).
It's nice about finding the posts a user looked... From the user profile or activities
Totally right.
Since it's just +/- the current number doesn't matter at all. The reason that the only type setted on the table needs to be counter.