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

Good system design

seangoedecke.com

Post reply on HN
Print view View original

131–140 of 400 posts

Re: Good system design

#131

Post by alixanderwang »

> I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design.

For any job-hunters, it's important you forget this during interviews.

In the past I've made the mistake of trying to convey this in system design interviews.

Some hypothetical startup app

> Interviewer: "Well what about backpressure?"

>"That's not really worth considering for this amount of QPS"

> Interviewer: "Why wouldn't you use a queue here instead of a cron job?"

> "I don't think it's necessary for what this app is, but here's the tradeoffs."

> Interviewer: "How would you choose between sql and nosql db?"

> "Doesn't matter much. Whatever the team has most expertise in"

These are not the answers they're looking for. You want to fill the whiteboard with boxes and arrows until it looks like you've got Kubernetes managing your Kubernetes.

Re: Good system design

#132

Post by dondraper36 »

alixanderwang wrote: post #131

> I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design. For any job-hunters, it's important you forget this during interviews. In the past I've made the mistake of trying to convey this in system design interviews. Some hypothetical startup app > Interviewer…

Yes, and this is exactly why LinkedIn-driven development exists in the first place. Listing a million technologies looks much more impressive on paper to recruiters than describing how you managed to only use a modular monolith and a single Postgres instance to make everything work.

Re: Good system design

#133

Post by tossandthrow »

radlad wrote: post #117
tossandthrow wrote: post #113

Earlier quoted context omitted.

It is a granluarity tradeoff. With SQL you need to explicitly test all queries where the shape granularity is down to field level. When you map data onto an object model (in the dto sense, not oop sense) you have bigger building blocks. This gives a simpler application that is more reliable. Obviously you need to pick a performant orm - and it seems a lot of people in these threads have been traumatized. Personally,…

The issue with GraphQL tends to be unoptimized joins instead. Is your GraphQL API available for public consumers? How do you manage them issuing inefficient queries? I've most often seen this countered through data loaders (batched queries that are merged in code) instead of joins, or query whitelists.

While this api in particular is not publicly exposed, that would not be a concern.

The key is to hold the same schema on the database as on the graphql and use tooling that can translate a gql query into a single query.

Re: Good system design

#134

Post by tossandthrow »

Yokohiii wrote: post #121
tossandthrow wrote: post #113

Earlier quoted context omitted.

It is a granluarity tradeoff. With SQL you need to explicitly test all queries where the shape granularity is down to field level. When you map data onto an object model (in the dto sense, not oop sense) you have bigger building blocks. This gives a simpler application that is more reliable. Obviously you need to pick a performant orm - and it seems a lot of people in these threads have been traumatized. Personally,…

In my ears that's just neglect? You assume your ORM does the basic data mapping right and don't verify it?

No? The difference is to verify it ones for the orm VS ones for every single place your query.

Re: Good system design

#135

Post by loglog »

Yokohiii wrote: post #119
tialaramex wrote: post #95

Earlier quoted context omitted.

Stored procedures seem like a win but the big problem is that while I could write the rest of the software in a very nice modern language like Rust, or more practically in C# since my team all know C# if I write a stored procedure it will be in Transact-SQL because that's the only choice. T-SQL was not a good programming language last century when it was vaguely current, and so no I do not want to write any significa…

I've only once tried to use stored procedures in mysql and it was almost impossible to debug back then. Very painful. Average devs already have issues being smart with their databases and stored procedures would add to that. Stored procedures also add another risk. You have to keep them in sync with code, making releases more error prone. So you have to add extra layers of complexity to manage versioning. I can see t…

> Stored procedures also add another risk. You have to keep them in sync with code, making releases more error prone.

This one is easily solved: never change a stored procedure. Every version should get a new name.

Re: Good system design

#136

Post by hks0 »

The article starts by criticizing generic rules that come without any context:

> Even good system design advice can be kind of bad. I love Designing Data-Intensive Applications, but I don’t think it’s particularly useful for most system design problems engineers will run into.

But continues to do the same throughout the rest of its advices. It also says:

> ... Drawing the line here is a judgment call and depends on specifics,

And immediately mentions:

> but in general I aim to have my tables be human-readable ...

Which to me reads as "I'm going to ignore the difference of the context everywhere and instead apply mine for everyone, and I'm going to assume most of the wolrd face the same problems as me". It's even worse than the book being criticized in the beginning, as the book at least has "Data-Intensive" in its title.

This is quiet easily fixable. The author can describe the typical scenario they are working with on a day-to-day basis. Do they work with 10 users a day? 100? 10,000,000? What is the traffic? How many engineers? What's the situation of the team/company; do FIXMEs turn into fixes or they become it's a feature? And so on.

In the end, without setting a baseline, a lot of engineers will start pointing fingers at each other dismissing the opposite ideas because it doesn't fit their situation. The reasoning might be true, but before that, it is "irrelevant", hence any opposition to or defending of it.

Re: Good system design

#137

Post by lutzh »

The only thing I know about “good system design” is that it doesn’t exist in the abstract. Asking whether an architecture is good or bad is the wrong question. The real question is: Is it fit for purpose? Does it help you achieve what you actually need to achieve?

I could nitpick individual points in the article, but that misses the bigger issue: the premise is off.

Don’t chase generic advice about good or bad design. First understand your requirements, then design a system that meets them.

Re: Good system design

#138

Post by msiyer »

lutzh wrote: post #137

The only thing I know about “good system design” is that it doesn’t exist in the abstract. Asking whether an architecture is good or bad is the wrong question. The real question is: Is it fit for purpose? Does it help you achieve what you actually need to achieve? I could nitpick individual points in the article, but that misses the bigger issue: the premise is off. Don’t chase generic advice about good or bad design…

... that is how you achieve a good design (for the time being).

Re: Good system design

#140

Post by wahnfrieden »

sethammons wrote: post #123
motorest wrote: post #92

What a great article. It's always a treat to read this sort of take. I have some remarks though. Taken from the article: > Avoid having five different services all write to the same table. Instead, have four of them send API requests (or emit events) to the first service, and keep the writing logic in that one service. This is not so cut-and-dry. The trade offs are far from obvious or acceptable. If the five services…

The goal is to minimize what needs changing when things need changing. When you need to alter the datastore, usually for product or scalability, you have to orchestrate all access to that datastore. Ergo: one only one thing using the datastore means less orchestration. At work, we just updated a datastore. We had to move some tables to their own db. 3 years later, 40+ teams have updated their access. This was a produ…

A reused code library for DB use is an alternative there
Post reply on HN