Ruby backend probably, at least to start with. If later on the application hits capacity and it reaches the limit of ruby, it can be dealt with then. Single monolithic app, no services at this point. App would be responsible for serving up an API which would be consumed by probably a React or Angular front end. UUIDs are a must.
Hard to go wrong with PostgreSQL at this point. But I would probably do it more in a CQRS structure. Separating my reads from my wrights. Events come in, aggregators listen for events they care about and then populate projections tailored to the queries that are needed. ie: Comment Projection would be a list of comments, with user info. If a user were to update their username, an aggregator would be solely responsible for updating the users info in every instance in those projections. Projections would power api endpoints. New endpoint, new projection. Store the info in the way you want to consume it. Possibly caching certain queries in redis.
at this point our applications artictecturhe looks sort of like this:
Front End -> Action by user -> Aggregators Deals with Action -> Projections Get Updated -> Front End gets updated data.
Projections dont have to be PostgreSQL, they could be any sort of store that is optimised to server the data in the required format quickly. Not all projections have to be the same either. One could be Mongo or Redis if you wanted. They can be versioned and scaled horizontally with master slaves. The original PostgreSQL is pretty much just there for storing events in a repayable idempotent way.
As the application grows we can then pull out services (aggregators/projections) to increase performance and scalability. As long as they can subscribe to the events, they can be written in anything you or your team at this point wants, GO, Erlang, Scala, .net, doesnt really matter as long as something like the load balancer or a routing layer can point API endpoints at them.
But start simple, single app, events, UUIDs, api, solid front end, single domain. Event comes in, projections get updated, single api endpoint maps to single projection. A comment projection shouldnt have to ask about the users info, it should already know.