0

I am finding some difficulties in the data modeling of an application which may involve the use of counters.

The app is basically a messaging app. Messages are bounded for free users, hence the initial plan of using a counter column to keep track of the total count.

I've discovered that batches (logged or not) cannot contain operations on both standard tables and counter ones. How do I ensure correctness if I cannot batch the operation I am trying to perform and the counter update together? Is the counter type really needed if there's basically no race condition on the column, being that associated to each individual user?

My second idea would be to use a standard int column to use only inside batches. Is this a viable option?

Thank you

riccamini
  • 1,161
  • 1
  • 13
  • 29
  • Possible duplicate of [Counter Vs Int column in Cassandra?](https://stackoverflow.com/questions/35412377/counter-vs-int-column-in-cassandra) – Ashraful Islam Jun 06 '17 at 16:02
  • Thank you, I've read the question. It states that the counter type is needed to avoid race conditions. In my case I don't think I will have that, since the column is dedicated to each user. Is ok to use a standard int column if that's the situation? – riccamini Jun 06 '17 at 18:20
  • Can you guarantee that (for example) the same user won't use two devices concurrently? – xmas79 Jun 07 '17 at 07:54

1 Answers1

0

If you can absolutely guarantee that each user will produce only one update at time then you could rely on plain ints to perform the job.

The problem however is that you will need to perform a read-before-write anti-pattern. You could solve this as well, eg skipping the read part by caching your ints and performing in-memory updates followed by writes only. This is viable by coupling your system with a caching server (e.g. Redis).

And thinking about it, you should still need to read these counters at some point, because if the number of messages a free user can send is bound to some value then you need to perform a check when they login/try to send a new message/look at the dashboard/etc and block their action.

Another option (if you store the messages sent by each user somewhere and don't want to add complexity to your system) could be to directly count them with a SELECT COUNT... type query, even if this could be become pretty inefficient very soon in the Cassandra world.

xmas79
  • 5,060
  • 2
  • 14
  • 35
  • I suppose I will go with the cache solution for the initial counter read part, and then a batch of the count update and the message itself to ensure consistency. Still, as you said, this is all dependent to the fact that we manage to avoid race conditions for the counter. I do not see instead a different solution using the counter type, am I wrong? Thank you – riccamini Jun 07 '17 at 09:02