Live data from Hacker News

What we talk about when we talk about system design

maheshba.bitbucket.io

11–20 of 37 posts

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

#11
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. And worse still you can't even see a lot of the complexity easily as it's hidden in how the distributed system is configured. A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It'…

> 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.

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

#12
> New designs should be described in terms of the design space, so you can immediately convey their relative position compared to other point solutions. Expect a lot of statements of the form: “all solutions must do X”; “solution Y is just X with one change"

Except that as a developer when I hear "solution Y is just X with one change", I know that this is BS and that there won't be just that change which will be annoying because I'll have to refactor later..

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

#13
Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer).

To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going system design process - especially when it comes to the software part, and they’re often not very good at the non-software part either.

I find myself a little bit stuck doing hands-on software engineering for companies who’ve gotten themselves into a system design hole. Companies are willing to throw tremendous resources at paying for system design mistakes, but not at avoiding them, or correcting them.

I don’t really know how to profitably find my way upward, except for becoming a manager or a consultant.

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

#14

Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…

> To me, it’s clear that designing systems is the way to maximum ongoing profit

This is a huge claim. If true, then the way to profitably find your way upward is similar to what the linked article itself is doing:

Write about it, in a credible way, build your reputation as a person that can drive change leading to results, and then become a consultant.

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

#15

Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…

> To me, it’s clear that designing systems is the way to maximum ongoing profit This is a huge claim. If true, then the way to profitably find your way upward is similar to what the linked article itself is doing: Write about it, in a credible way, build your reputation as a person that can drive change leading to results, and then become a consultant.

Well, yes. Self promotion & selling yourself IS exactly that

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

#16
I'm relatively new in this and recently I've been reading and hearing a lot about how distributed systems are overused and usually a monolith can do a better job etc. I'm working at a company serving millions of customers and distributed systems are utilized, most of my experience as a software engineer was built around this to the point that I was never around a codebase that is 10/20k+ lines of code. I feel like I lack some skills in modular monolith coding skills. My question is what kind of sources can I read to improve my understanding of monolith vs microservices, when to use each, and the tradeoff of preferring one over the other?

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

#17

I'm relatively new in this and recently I've been reading and hearing a lot about how distributed systems are overused and usually a monolith can do a better job etc. I'm working at a company serving millions of customers and distributed systems are utilized, most of my experience as a software engineer was built around this to the point that I was never around a codebase that is 10/20k+ lines of code. I feel like I…

The SRE book is a decent reference, but may not be exactly what you're looking for:

https://google.github.io/building-secure-and-reliable-system...

> hearing a lot about how distributed systems are overused and usually a monolith can do a better job etc

> improve my understanding of monolith vs microservices, when to use each, and the tradeoff of preferring one over the other

A lot of this will depend on where you're working. Where I'm at, the preference is for single tasks up to somewhere in the neighborhood of 200 gigs of RAM and commensurate CPU. Our individual servers have just stupid amounts of RAM and CPU on them, and our deployment stack has..... nontrivial amounts of overhead for.... reasons.

But if you're e.g. deploying on AWS, the price optimization point is gonna be different. And if you're deploying while working at Amazon it'll be yet a different tradeoff (cynically, having more to do with pager duty boundaries)

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

#18

Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…

When you are in a system design hole it's best to keep digging -- every company I ever worked for.
Post reply on HN