Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don't need a database, a queue, a distributed system: Go is enough

simonedutto.github.io

Post reply on HN
Print view View original

11–20 of 37 posts

Re: You don't need a database, a queue, a distributed system: Go is enough

#11

Post by gwd »

sgundo wrote: post #5
rapsey wrote: post #4

If you are working on this specific silly use case. What is the point of this article?

I agree it's silly, but sometimes ideas or POCs are silly but worth shipping. Don't you agree?

Worth shipping, but not worth investing massive amounts of time in.

On the other hand, suppose you actually hoped to grow and make enough money on something to pay the salary of a few dozen people. Let's say you start with golang and sqlite3, ready to handle 1000s of people an hour, everything is going great, and then someone posts your thing to Hacker News (or it goes viral elsewhere). Suddenly you have millions of eyeballs an hour, of whom your non-scalable infrastructure turns away 99.9%. What's the chance you get another shot after you've re-architected everything to be more scalable?

I don't have a good idea how likely that is; at some point I seem to recall hearing that Stack Overflow was run on just two servers, made possible because it was just efficient. But it's certainly something to take into consideration if you're hoping to grow large; and only something to ignore if you don't really care.

Re: You don't need a database, a queue, a distributed system: Go is enough

#12

Post by yanis_t »

We developers take proud for being able to get our head around a complex solution. And unfortunately sometimes that becomes a driver for building complex solutions for problems, that otherwise could have been solved much simpler. But in that case we loose interest.

Me, personally, I often find myself in situations like this. Where if I clearly understand the solution in my head, I might be a bit reluctant to actually code it and get the job done. Kinda like, you know the solution exists, and then you move on to something more interesting.

Re: You don't need a database, a queue, a distributed system: Go is enough

#15

Post by boutell »

Can attest - for similar use cases. I did much the same (shameless plug, just like the original): https://friendsyeights.com/

Game state is kept in memory, the server is single process (Node.js as it happens), connections use websockets, it just works.

Does it scale? No. Could it scale with a similar approach? Sure, with some additional work: separate games could be distributed over many instances (a sharding strategy). There's no redundancy there, but it's a game, not a credit card processing system.

However, I do snapshot game state in JSON files on disk so that games are not terminated by every new deployment. In a single-process model, that's safe when using synchronous filesystem calls. Just don't try it in a multithreaded system. Though it may take many moons, you will eventually lose your "poor man's database" to a race condition.

Still, would I use this technique to host people's taxes? Hard no. I wouldn't even use it to host their blog posts. Durability matters for those use cases.

Re: You don't need a database, a queue, a distributed system: Go is enough

#16

Post by jstanley »

sgundo wrote: post #7
phyrex wrote: post #6

I don’t disagree with the premise for very small applications, but > The quiz state machine is full in memory > The queue system for the matchmaking is in memory Means those will be nuked as soon as a new version gets uploaded. it really wouldn’t have been much extra work to put this into SQLite as well, and would lead to a much better user experience during updates

You are right, but i can roll updates during the night without causing any issue. Since after you finished playing you don't have a way to access your old games anymore

> i can roll updates during the night without causing any issue

This isn't universally true.

I work on a telephony platform, some components of which need to be upgraded very carefully, because if you just restart the daemon without first transferring load elsewhere then you drop people's calls.

OK, there are less calls at night time, but there are calls all of the time and people don't expect their calls to randomly drop just because it's night time.

Re: You don't need a database, a queue, a distributed system: Go is enough

#18

Post by 9dev »

sgundo wrote: post #7
phyrex wrote: post #6

I don’t disagree with the premise for very small applications, but > The quiz state machine is full in memory > The queue system for the matchmaking is in memory Means those will be nuked as soon as a new version gets uploaded. it really wouldn’t have been much extra work to put this into SQLite as well, and would lead to a much better user experience during updates

You are right, but i can roll updates during the night without causing any issue. Since after you finished playing you don't have a way to access your old games anymore

That works for the specific case presented here. As soon as you have users from other timezones, ”during the night“ becomes a really complicated concept quickly.

Re: You don't need a database, a queue, a distributed system: Go is enough

#20

Post by sgundo »

queil wrote: post #10

It's a bit click-bait-ish. You don't need computers, here is my tic-tac-toe on a piece of paper + pen. Just use the right tool for the job.

Yeah, it is kind of provocatory. Of course you can't build a business out of an in-memory game, but it is fun to ship something as it is. Without thinking too much about scalability.
Post reply on HN