Good system design
seangoedecke.com
Good system design
1–10 of 400 posts
Re: Good system design
#2The advice about logging and metrics was good.
I had been nodding away about state and push/pull, but this section grabbed my attention, since I’ve never seen it do clearly articulated before.
Re: Good system design
#3He doesnt seem to mention Conway or team topology which is an important part of system design too.
Re: Good system design
#4The advice about logging and metrics was good. I had been nodding away about state and push/pull, but this section grabbed my attention, since I’ve never seen it do clearly articulated before.
The logging part is spot on. It has happened so many times when I thought, "Oh, I wish I had logged this.", and then you face an issue or even an incident and introduce these logs anyways.
Re: Good system design
#5The advice about logging and metrics was good. I had been nodding away about state and push/pull, but this section grabbed my attention, since I’ve never seen it do clearly articulated before.
Yes. Everyone should spent the small amount of time getting some logging/metrics going. It's like tests, getting from 0-1 test is psychologically hard in a org but 1-1000 then becomes "how did I live without this". Grafana has a decent free tier or you can self host.
Re: Good system design
#6The advice about logging and metrics was good. I had been nodding away about state and push/pull, but this section grabbed my attention, since I’ve never seen it do clearly articulated before.
The logging part is spot on. It has happened so many times when I thought, "Oh, I wish I had logged this.", and then you face an issue or even an incident and introduce these logs anyways.
It is a balance. Too many logs cost money and slow down log searches both for the search and the human seeing 100 things on the same trace.
Re: Good system design
#7He doesnt seem to mention Conway or team topology which is an important part of system design too.
Well, as sad as it is, such advice is often applicable to new projects when you still have runway for your own decisions.
For mostly political reasons, if you are onboarded to a team with a billion microservices and a lot of fanciness, it's unlikely that you will ever get approval or time to introduce simplicity. Or maybe I just got corrupted myself by the reality where I have to work now.
Re: Good system design
#8Earlier quoted context omitted.
The logging part is spot on. It has happened so many times when I thought, "Oh, I wish I had logged this.", and then you face an issue or even an incident and introduce these logs anyways.
It is a balance. Too many logs cost money and slow down log searches both for the search and the human seeing 100 things on the same trace.
Yeah, absolutely. But the author's idea of logging all major business logic decisions (that users might question later) sounds reasonable.
Re: Good system design
#9Earlier quoted context omitted.
It is a balance. Too many logs cost money and slow down log searches both for the search and the human seeing 100 things on the same trace.
Yeah, absolutely. But the author's idea of logging all major business logic decisions (that users might question later) sounds reasonable.
Yes. I like the idea of assertions too. Log when an assertion fails. Then get notified to investigate.
Re: Good system design
#10He doesnt seem to mention Conway or team topology which is an important part of system design too.
Well, as sad as it is, such advice is often applicable to new projects when you still have runway for your own decisions. For mostly political reasons, if you are onboarded to a team with a billion microservices and a lot of fanciness, it's unlikely that you will ever get approval or time to introduce simplicity. Or maybe I just got corrupted myself by the reality where I have to work now.
There is definitely a wood for the trees issue at bigger companies. I doubt there is an architect who understands the full system to see how to simplify it. Hard to even know what "simpler" looks like.