Thanks for asking.

First off, this is a tough question and we could go for pre-optimizations or preferences. I'm missing certain information but lets assume the videos are not transformed by the server (no direct streaming) and the database is a dedicated instance and I only have 2GB of RAM.

Because of the memory limits, most noSQL solutions are out of the picture. We could ofc look into certain other implementations, but mongodb, couchdb, cassandra, elasticsearch, etc are out of the picture with a minimum of 4GB-8GB RAM.

We just need a sequence +1, -1, +1, -1 for the likes and the page views per definition are only +1. these don't have to be in the right order !! this is important because it makes our life easier :).

With only 1000 concurrent requests to our server we can easily handle this with an SQL database and a Queue in front of it. I would go with mySQL + TokuDB engine.

Why MySQL ?

you could ofc take pgSQL as well, it's a good an solid solution and you probably won't hit too many bottlenecks. But pgSQL shines with roles and features that we don't need for this features/purpose + eng.uber.com/mysql-migration

SQL is good with reads but not that good with writes, that's where TokuDB kicks in -> buffer index updates -> en.wikipedia.org/wiki/TokuDB this should help speed up the write to an acceptable level

Why the queue ?

MySQL memory consumption is roughly

key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections;

dev.mysql.com/doc/refman/5.7/en/memory-use.html

so I will take my default machine setup

16MB + 0.25MB + 0.5MB = 16.75MB per connection. My default setting of connections is 131 which is not much but this would be 2194.25 MB of RAM

So we just add a buffer in our case a simple queue in front. I am a fan of lightweight zeroMQ since we have memory limitations, but if we just allow 10 concurrent connections from the workers with 10 spare ones for us and other services we are down to 335MB of RAM and we should just up certain buffers so we have around 1GB of RAM for the database.

The queue needs some low memory workers this is where I would use a small golang service just because the memory handling is more precise. You can use Node as well. Java is off topic, because of memory reason, C is to tricky and languages like Erlang/Elixir might also exceed the memory footprint we want. PHP might work but you would have to kill and restart the service regularly to control the memory. -> As I mentioned to me it's a job for golang or Rust but golang is more accessible to transition to, for most devs.

I would use a 1:n messaging system and actually keep the read and the write separate a CQRS martinfowler.com/bliki/CQRS.html pattern that will be updated by the queue alongside with the SQL database. Would come to mind .... if you're a JS guy basically it's redux. if you are more about c# CQRSlite. This helps to avoid unnecessary reads.

Which leads to the next problem -> the reads have to be requested via queue as well otherwise we would already need a different pattern.

I hope this helps, I am sure there are a lot of specialists out there who wholeheartedly disagree with me, and this is just 1 solution picked based on the constraints you told me.

You could for example use couchdb with pouchdb and wouldn't need a queue but this would need 4GB RAM as minimum. But it has a different paradigm behind it and a different memory footprint and so on.