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

What we talk about when we talk about system design

maheshba.bitbucket.io

Post reply on HN
Print view View original

21–30 of 37 posts

Re: What we talk about when we talk about system design

#21

Post by karaterobot »

efishnc wrote: post #19

> The goal of the design process is (...) to instead characterize the design space for a given problem Any good resources on how to properly define the design space? What makes it a space more than a list of requirements?

I am interpreting it as an n-dimensional graph (let's say 2D for simplicity), and the axes may be something like "speed" and "scale", or "cost" and "risk", or whatever your parameters happen to be. The solution is somewhere in the space defined by those axes, but you don't know where it is yet, and you don't want to lock yourself in to a single point too early. The axes themselves could be anything. You are choosing what to care about. Ideally, it should be informed by understanding your users, your stakeholders, your domain, your market, resources, available technology, divine inspiration, etc., but it's an important decision that is probably completely contextual and is part of the design process.

I could be wrong, this is, as noted, just an interpretation.

Re: What we talk about when we talk about system design

#22

Post by joseph »

> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals).

This is so true. It’s very common to see infrastructure being built in terms of the application that will run on it instead of designing the application to run on the infrastructure. A lot of brittle, unmodifiable messes are the result of this.

Re: What we talk about when we talk about system design

#25

Post by heisenbit »

> Late-bind on designs. The goal of the design process is not to generate a single point solution, but to instead characterize the design space for a given problem: a single point should then fall naturally out of that space given the problem constraints.

There is also value in early binding combined with a willingness to iterate. There is a lot of knowledge to be gained by trying to do things rather than staying on design level. I‘m making the comment not to contradict the author but to stress that exploring the design space can also mean doing things for real. The risks with a wrongly applied late biding are superficial designs and design paralysis.

Re: What we talk about when we talk about system design

#26

Post by paulryanrogers »

joseph wrote: post #22

> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals). This is so true. It’s very common to see infrastr…

Part of the challenge is knowing how to slice the layers and when. Premature optimization is often crossing such layers too soon. Yet there are times when it becomes necessary for performance, such as Oracle bypassing FS to write to block devices or kernel patches for specialized networking cases.

Re: What we talk about when we talk about system design

#27

Post by [deleted] »

joseph wrote: post #22

> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals). This is so true. It’s very common to see infrastr…

[deleted]

Re: What we talk about when we talk about system design

#28

Post by john-tells-all »

heisenbit wrote: post #25

> Late-bind on designs. The goal of the design process is not to generate a single point solution, but to instead characterize the design space for a given problem: a single point should then fall naturally out of that space given the problem constraints. There is also value in early binding combined with a willingness to iterate. There is a lot of knowledge to be gained by trying to do things rather than staying on…

Strongly agree.

Design Workflow:

- spend little time making a couple design decisions -- lots of handwaving and "we'll figure it out"

- bind these decisions, then write a tiny app to see what it looks like. What are the technical consequences? What are the business consequences (including risks)? How does this affect development?

- repeat 2-4x. The goal is to maximize speed of feedback, at the cost of minimal scope and low quality. That's fine.

- iterate more, expanding the scope and quality as needed

- you're done!

Use high-level diagrams to help focus the effort. This dramatically helps discussions with stakeholders and developers.

Source: writing a book on feedback loops

Re: What we talk about when we talk about system design

#29

Post by gsuuon »

heisenbit wrote: post #25

> Late-bind on designs. The goal of the design process is not to generate a single point solution, but to instead characterize the design space for a given problem: a single point should then fall naturally out of that space given the problem constraints. There is also value in early binding combined with a willingness to iterate. There is a lot of knowledge to be gained by trying to do things rather than staying on…

Yes this is more the tinkerer vs inventor approach, but sometimes tinkering is way more pragmatic in understanding a space.

Re: What we talk about when we talk about system design

#30

Post by rewmie »

rcxdude wrote: post #11
rewmie wrote: post #10

Earlier quoted context omitted.

> With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. The goals of system design are a) a system actually works, b) the system is not a colossal mess. In a similar manner, the challenge of any engineering field is to not allow things to become overly complex. > A normal system design, der…

Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design.

> Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design.

"Can" and "do" are two different words.

"Monolith" is often a cop out to hide amorphous big-ball-of-mud projects. In fact, the luddite-like movement's aversion to system design is rooted in the fact that it's not necessary, and their irrational aversion to microservices and distributed systems and systems design lies in the fact that, unlike monoliths, they are far less tolerant of hacking together big balls of mud and demand instead some degree of discipline to design a system and comply with the system design.

Post reply on HN