Live data from Hacker News

Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

github.com

11–20 of 59 posts

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#13

Earlier quoted context omitted.

I think they mean, why introduce this new piece of infrastructure when you can create this internally with a singular table and probably a queue somewhere if we're being really fancy.

I think you can def do it on a low scale. You would not need this tech. At least not the Kafka / Timescale feature. It would place nice if you were a bit bigger - a news website, a social media and so on.

> It would place nice if you were a bit bigger - a news website, a social media and so on.

How big do you think is "big"? I run a system that handles about 3k requests per second (~1:100 writes to reads). No caching, no Redis, just Postgres. One master and a hot standby for failover. It sits around 25% CPU, and most of that is from opening and closing connections rather than queries.

There's an important lesson in avoiding complexity for speculative reasons. Unless you have data that suggests more components materially improve the system, save yourself the heartache and build for the simplest system that meets your needs. You've built a dump truck when you probably only need a pickup truck, and while you might need more than a pickup truck someday, you're paying dump truck maintenance costs in the meantime (and your future needs probably look more like a King Ranch than a dump truck anyway).

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#14

I love how in the age of good old PHP, Django and alike this would be insanity. But with serverless it makes sense I guess.

Nonsense! You could build this with Django Channels with no problem. There's nothing about this system that makes Django (or really any other framework) a poor choice.

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#15

Why do you need Kafka, Redis, Mongo, AND Postgres? Arguably it could all be done with Postgres or Redis: both have great pubsub implementations. But what could you possibly need two databases for and a queue implementation alongside a popular backend for queues? I don't mean to criticize, but the complexity of this is what I'd expect for something handling hundreds if not thousands of qps. Even then I'd expect you co…

Résumé Driven Development.

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#16

Earlier quoted context omitted.

I think you can def do it on a low scale. You would not need this tech. At least not the Kafka / Timescale feature. It would place nice if you were a bit bigger - a news website, a social media and so on.

> It would place nice if you were a bit bigger - a news website, a social media and so on. How big do you think is "big"? I run a system that handles about 3k requests per second (~1:100 writes to reads). No caching, no Redis, just Postgres. One master and a hot standby for failover. It sits around 25% CPU, and most of that is from opening and closing connections rather than queries. There's an important lesson in av…

It's not a big problem to create another version without Kafka, and use Postgres :)

What do you think about the idea?

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#17

Earlier quoted context omitted.

I think they mean, why introduce this new piece of infrastructure when you can create this internally with a singular table and probably a queue somewhere if we're being really fancy.

I think you can def do it on a low scale. You would not need this tech. At least not the Kafka / Timescale feature. It would place nice if you were a bit bigger - a news website, a social media and so on.

How many clicks per second on an item would justify this architecture? Ballpark numbers and napkin math estimates is fine - again it would seem reasonable if justified.

If I’m gonna get that many clicks per second, it’s likely I’ll already have my own analytics system, queue system, cache architecture, application database. Why adopt this external code when I’ll spend more work integrating it into my application compared to building it myself?

If I’m small, why spend all the work or subscribe to your managed product when a very simple CRUD approach using only my app database and polling will suffice?

Anyways that’s my perspective. There’s probably some market out there but I’m not part of it, that’s all I’m saying.

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#18

Why do you need Kafka, Redis, Mongo, AND Postgres? Arguably it could all be done with Postgres or Redis: both have great pubsub implementations. But what could you possibly need two databases for and a queue implementation alongside a popular backend for queues? I don't mean to criticize, but the complexity of this is what I'd expect for something handling hundreds if not thousands of qps. Even then I'd expect you co…

As for Postgres, I chose Timescale because you can easily change it at any time for Postgres. I plan to have it as a managed service in the future, which means that it will hold a lot of clients - some big, some small. But I think I should def make another smaller version without Kafka and Timescale.

When it is a managed service, will a single individual be feeding into a single sort of taste profile over multiple sites?

Actually am I crazy to thing that wouldn’t be the worst thing in the world? Tracking people across multiple sites without their informed consent is of course totally unethical spying, but if it is clear that they are consciously interacting with UI like yours and they know it is shared, that doesn’t seem so bad. (?)

And it could be nice if Pandora would start suggesting soundtracks to movies I’ve upvoted on Amazon or something like that…

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#19

Why do you need Kafka, Redis, Mongo, AND Postgres? Arguably it could all be done with Postgres or Redis: both have great pubsub implementations. But what could you possibly need two databases for and a queue implementation alongside a popular backend for queues? I don't mean to criticize, but the complexity of this is what I'd expect for something handling hundreds if not thousands of qps. Even then I'd expect you co…

As for Postgres, I chose Timescale because you can easily change it at any time for Postgres. I plan to have it as a managed service in the future, which means that it will hold a lot of clients - some big, some small. But I think I should def make another smaller version without Kafka and Timescale.

Even if you were managing this for third parties, there's no reason to assume your scale would necessitate this complexity. One of my Postgres databases stores analytics data for podcasts. 800gb worth in two tables. It's just vanilla Postgres with indexes. P90 queries complete in 100ms. I serve >10k customers with one write instance and one read-only replica. Some podcasts get thousands of listens per second at peak times.

Stripe relied entirely on Mongo for storage and queueing at a scale that you'll almost assuredly never reach. That's probably inadvisable today, but the point is that the more systems you have, the more systems you need to maintain and the more things that can break and the more places you'll eventually find bottlenecks.

Re: Show HN: Clickvote – Open-source upvotes, likes, and reviews to any context

#20

I love how in the age of good old PHP, Django and alike this would be insanity. But with serverless it makes sense I guess.

Can you elaborate on this? ^_^

The point is that this crazy architecture could (perhaps) only be justified if all my backend is outsourced to external serverless points.

The moment that I need to have my own backend to manage some data, I can add the item rating data as well and your system becomes more complex than the built-in solution.

Post reply on HN