Live data from Hacker News

Building a highly-available web service without a database

blog.screenshotbot.io

111–120 of 187 posts

Re: Building a highly-available web service without a database

#111
post #107
post #105

Earlier quoted context omitted.

I don’t want to go ad personam on the blog author - but checking his socials he is not really experienced person. I don’t think we have anything to discuss here. He seems just to want to do cool stuff and his drop of databases seems to be because he just doesn’t know a lot of stuff there is to know. I applaud attempt and might be that his needs will be covered by what he is doing. But for everyone else yes, pick bori…

> but checking his socials he is not really experienced person. I'm not sure what qualifies as experience if Meta/Google doesn't. ;)

[deleted]

Re: Building a highly-available web service without a database

#112
post #56
post #47

Earlier quoted context omitted.

Trading systems bluntly keep everything in RAM, in preallocated structures. It all depends on the kind of tradeoffs you're willing to make.

I used to work on a telecom platform (think something that runs 4G services), where every node was just part of an in-memory database that replicated using 2PC and just did periodic snapshot to avoid losing data. Basically processes were colocated with their data in the DB.

I worked on a lottery / casino system that was similar. In memory database ( memory mapped files), with a WAL log for transaction replay / recovery. There was also a periodic snapshot capability. It was incredibly low latency on late 90's era hardware.

Re: Building a highly-available web service without a database

#113
post #97

Earlier quoted context omitted.

redis and mongo are the type of things i will yak shave to no ends so i don't have to deploy them in production

I’m honestly not sure what you are talking about. In my experience, Redis is super easy to run and manage in production.

If you like split brains, yes. :)

Re: Building a highly-available web service without a database

#114
post #98

Earlier quoted context omitted.

To throw the question back at you: have you considered that this isn't complicated?

No I haven’t because it’s quite complicated. Databases are very much a solved problem. Unfortunately, this architecture is going to be nigh impossible to hire for and when it goes absolutely sideways recovery will be difficult.

That’s the best part, you don’t realize when things go sideways.

Re: Building a highly-available web service without a database

#115
post #57
post #40

Earlier quoted context omitted.

probably uses the filesystem as the backing store

Filesystems these days are like dbs

Good luck transactionally writing files to a random FS, but especially without access to native OS APIs.

Re: Building a highly-available web service without a database

#116
I've got a handful of small Go applications where I just have a "go generate" command that generates the entire dataset as Go, so the data set ends up compiled into the binary. Works great.

https://emoji.boats/ is the most public facing of these.

I also have built a whole class of micro-services that pull their entire dataset from an API on start up, hold it resident and update on occasion. These have been amazing for speeding up certain classes of lookup for us where we don't always need entirely up to date data.

Re: Building a highly-available web service without a database

#117
Check out https://eclipsestore.io (previously named Microstream) if you're into Java and interested in some of the ideas presented in this article. You use regular objects, such as Records, and regular code, such as java.util.stream, for processing, and the library does snapshotting to disk.

I haven't tried it out but just thinking of how many fewer organizational hoops I would have to jump through makes we want to try it out:

- No ordering a database from database operations.

- No ordering a port opening from network operations.

- No ordering of certificates.

- The above times 3 for development, test and production.

- Not having to run database containers during development.

I think the sweet spot for me would be in services that I don't expect to grow beyond a single node and there is an acceptance for a small amount of downtime during service windows.

Re: Building a highly-available web service without a database

#118
>RAM is super cheap

I think this has to be the number one misunderstanding for developers.

Yes, SSD in terms of throughput or IOPs has gone up by 100 to 10000x. vCPU performance per dollar has gone up by 20 - 50x. We went from 45/32nm to now 5nm/3nm, and much higher IPC.

But RAM price hasn't gotten anywhere near the same fall as CPU or SSD. It may have gotten a lot faster, you may be even getting to stick lots of memory with higher density chip and channels went from dual to 8 or 12. But if you look at the DRAM Spot price since 2008 to 2022, you will see the lowest DRAM price has been the same at around $2.8/GB for three times. As the DRAM price goes in cycle with $8 / $6 per GB in between this same period. i.e Had you bought DRAM at its lowest point or its highest point during the past ~15 years your DRAM would have cost roughly the same plus or minus 10-20% ignoring inflation.

It was only until Mid 2022 it finally broke through the $2.8/GB barrier and collapse close to $1/GB before settling on ~ $2/GB for DDR5.

Yes you can now get 4TB RAM on a server. But it doesn't mean DRAM are super cheap. Developers on average or for those in big Tech are now earning way more than they were in 2010. Which makes them think RAM has gotten a lot more affordable. In reality even in the lowest point over past 15 years you only get at best slightly more than 2x reduction in DRAM price. And we will likely see DRAM price shot up again in a year or two.

Re: Building a highly-available web service without a database

#119
post #105
post #96

There is so much wrong with this I don't know where to even start. You want to "keep things simple" and not stand up a separate instance of MySQL/Postgres/Redis/MongoDB/whatever else. So, you: 1. Create your own in-memory database. 2. Make sure every transaction in this DB can be serialized and is simultaneously written to disk. 3. Use some orchestration platform to make all web servers aware of each other. 4. Synchr…

I don’t want to go ad personam on the blog author - but checking his socials he is not really experienced person. I don’t think we have anything to discuss here. He seems just to want to do cool stuff and his drop of databases seems to be because he just doesn’t know a lot of stuff there is to know. I applaud attempt and might be that his needs will be covered by what he is doing. But for everyone else yes, pick bori…

>I don’t want to go ad personam on the blog author - but checking his socials he is not really experienced person.

According to LinkedIn:

- Masters in CS from UPenn

- 1 year as SWE at Google

- 6 years as SWE at FB/Meta

- 6 years running his own company

When I hear "not really experienced," I think recent college grad, not someone with a Master's and 15 years of industry experience.

Re: Building a highly-available web service without a database

#120
post #118

>RAM is super cheap I think this has to be the number one misunderstanding for developers. Yes, SSD in terms of throughput or IOPs has gone up by 100 to 10000x. vCPU performance per dollar has gone up by 20 - 50x. We went from 45/32nm to now 5nm/3nm, and much higher IPC. But RAM price hasn't gotten anywhere near the same fall as CPU or SSD. It may have gotten a lot faster, you may be even getting to stick lots of mem…

Simultaneously, many developers reach for distributed systems too quickly when they could just buy more ram. Perhaps that’s what the writer means
Post reply on HN