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

In defense of simple architectures

danluu.com

Post reply on HN
Print view View original

161–170 of 196 posts

Re: In defense of simple architectures

#161

Post by Beltalowda »

lelanthran wrote: post #149
Beltalowda wrote: post #95

Earlier quoted context omitted.

Your write will be fine; that is, it's not as if data from one write will be interspersed with the data from another write. It's just that the order might be wrong, or opening the file multiple times (possibly from multiple processes) could be fun too. The program or computer crashing mid-write can also cause problems. Things like that. Again, may not be an issue at all for loads of applications. But I used a lot of…

> Your write will be fine; that is, it's not as if data from one write will be interspersed with the data from another write. Are you sure? I thought it could be if the first write had more data than the size of the kernel/fs-driver buffer, not all of it would be written, and then it could be interrupted when another thread calls write() with a small buffer that gets written in one go.

No, I'm not sure haha; but in my experience it usually works like that, but no doubt there could be edge cases there, too. Another good reason to use SQLite.

Re: In defense of simple architectures

#162

Post by wink »

gmfawcett wrote: post #107
SpikeMeister wrote: post #87

Earlier quoted context omitted.

TechEmpower has benchmarks for different web stacks: https://www.techempower.com/benchmarks/

Unfortunately TE is highly gamified, and the benchmarks (like most benchmarks!) don't really represent real-world workloads.

True, but it's great that they have a certain comparable hello-world set, so you can just take the 2-n benchmarks for the tech you're interested in and either ungamify it or just implement your own prototype and measure. The benefit of already having a non-random-tutorial-from-google app is a huge win to me personally.

Re: In defense of simple architectures

#163

Post by ChrisMarshallNY »

yakshaving_jgt wrote: post #101
ChrisMarshallNY wrote: post #94

Earlier quoted context omitted.

I would assume bruised_blood, but I can't [easily] find the original, so I posted that.

No, sure. That’s fair enough. My point simply being that iamdevloper is a notorious joke thief and is especially unsporting about it when it’s pointed out.

I did not know that. Maybe it would have been better to spend more time trying to find the original comic (I guess maybe an image search. Doomscrolling @bruised_blood is a lost cause).

[EDITED TO ADD] I tried image search. No dice.

Re: In defense of simple architectures

#164

Post by zie »

bmn__ wrote: post #157
zie wrote: post #60

Earlier quoted context omitted.

Slack is not instantly "better" than IRC, it's just a different approach to the chat problem and it's arguably more approachable for people that don't want to learn about the chat space. Logging is just different between the two. For IRC, logging is outside the scope of the IRC protocol. Anyone can log anything anytime anywhere with whatever policies and procedures they want. This usually leads to each channel/projec…

> For IRC, logging is outside the scope of the IRC protocol. Nope, the community has understood that server-side logging (and making it available to clients who missed stuff happening) is a useful thing. https://ircv3.net/specs/extensions/chathistory

ah, neat! Looks like there are even deployed IRCv3 networks like libera.chat, very cool!

Re: In defense of simple architectures

#165

Post by mgraczyk »

lifefeed wrote: post #61

I was interviewing for software jobs recently, and while I was studying up on the "system design" portion I kept circling around the same insight that Dan Luu writes about so well here. I would sit down at an interview and try to create these "proper" system designs with boxes and arrows and failovers and caches and well tuned databases. But in the back of my mind I kept thinking, "didn't Facebook scale to a billion…

I ask a lot of system design interviews based on Facebook's products. What I look for is the ability to propose something simple, proposing the right metrics and data collection to understand scaling needs, then making reasonable guesses about which parts of the system need to scale. PHP + MySQL + Memcache is great until you also need to do ML inference (high CPU/GPU load), need to store user-uploaded video, or want to stream new content to users in near realtime (live comments).

They key is to add the minimum amount of "stuff" to a simple design to convincingly scale for some new hypothetical need.

Re: In defense of simple architectures

#166

Post by mwcampbell »

bob1029 wrote: post #9

I think the biggest problem for most developers is not understanding what one computer can actually do and how reliable they are in practice. Additionally, understanding of how tolerant 99% of businesses are to real-world problems that could hypothetically arise can help one not frustrate over insane edge case circumstances. I suspect a non-zero number of us have spent time thinking about how we could provide determi…

> "Failover requires manual intervention" is a feature, not a caveat.

I was scarred by the DDoS of Linode on Christmas Day 2015 (as a Linode customer at the time). I believe that was the only time my Christmas was ever interrupted by work. Of course, one might respond that being the one perpetually on-call sysadmin isn't ideal.

Re: In defense of simple architectures

#167

Post by trasz »

exfascist wrote: post #31
spicybright wrote: post #28

Earlier quoted context omitted.

I love irc, but is is just silly. Slack has much better history because you don't need to have been online when messages are sent to log them. Slack is absolutely more reliable in this regard. IRC is easy to script because the protocol is so simple. But you leave so much on the table for that cost. Obviously if your use case is text only that you don't care about being persistent and you lean heavily on scripting to…

IRC has logs for history, they're fast and you can run your own logger to control the retention policy if you want. These heavy weight IM tools have extremely short log retention (months) and searching through the logs is extremely slow and frustrating IME.

Not only that, but you can grep IRC logs using whatever Unix tools you want, which is much more powerful than anything Slack has to offer.

Re: In defense of simple architectures

#168

Post by woah »

treis wrote: post #66
woah wrote: post #46

Earlier quoted context omitted.

Probably depends on the requirements. If the product should basically feel like a static web page, and you are OK making design and product decisions that work easily in that paradigm, then a server side framework built to make static web pages is going to be simpler. If you have product or design requirements that it should feel more dynamic like a native app, then trying to patch that on top of a static webpage mig…

IMHO the important thing is where your data is. If can all be client side then write a SPA. If it's on the server then the more you do on the server the better. Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.

Every app will have a bunch of serverside data so IMO that's not really a consideration.

The great thing about SPAs is that your server now just returns a simple JSON API. It greatly simplifies the server side. It also tends to make things a lot easier to unit test on the server side. Also, it cleanly segments your staffing requirements. If your app is in some way non-trivial, you can have domain experts working on the backend, and just dumping json into http responses, and have a frontend engineer who doesn't understand any of the magic work on the frontend.

> Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.

Once you're doing this, your backend engineers are dealing with html in addition to whatever their real job is. If you want to have something other than your website consume your backend, you're rewriting stuff to output json anyway.

If you have no domain-specific computation happening and your service will only ever be consumed as a more or less static website, serverside web frameworks can be faster. For example, if you are building a blogging site, or maybe a CRM.

Re: In defense of simple architectures

#169

Post by aprdm »

bob1029 wrote: post #159
aprdm wrote: post #146

Earlier quoted context omitted.

Could you expand what you mean by keeping pointers and basic index in memory?

Pointers are tuples of (Id, LogOffset) and are used to map logical identities to positions of those objects in the append-only log. Indexes are usually a tuple of (Some64BitKey, Id) and are used to map physical business keys to logical object identities. These entries are only candidates in the case where the key material needs to be hashed and inspected for actual equivalence. One big advantage with this approach is…

Awesome, thank you for sharing!

Re: In defense of simple architectures

#170

Post by kragen »

dismantlethesun wrote: post #155
kragen wrote: post #152

Earlier quoted context omitted.

I think all of this was after their first billion users?

Cassandra was released in 2008. Facebook hit 1 billion users ~ 2012, and 2 billion ~ 2017. Back when Cassandra was released, they had a 'mere' 100 million users. Facebook stats: https://www.statista.com/statistics/264810/number-of-monthly...

Thanks for the correction! So the more correct statement would be that Facebook scaled to 100 million users with PHP, MySQL, and Memcache, and then to a billion users with Cassandra and Haystack, and then built all the other stuff after their first billion?
Post reply on HN