/tech/ - Technology

>>17847
Ugh, I have a systems design interview soon. Any recommended material to prepare?

the classic text

"Software Architecture in practice" is used by many universities in teaching software architecture and is canonically blessed by the IEEE SWEBOK (v3/v4 draft)

>>17848
yes, https://github.com/donnemartin/system-design-primer
has different study plans depending on how much time you have left (short / medium / long)

>>17849
Holy shit this is great. Thanks mate, it'll be a blessing since that's the part I usually suck at.

Speaking about software architecture, in my experience, software architecture tends to be defined very poorly due to a lack of knowledge of the domain and the impact of decisions down the road. Simply put, the nature of dependencies, the limitations of the technologies used, and requirements at the time of design are not known, so the architecture is completely bonkers, constantly coping for the actual requirements and limitations found while developing.

In my experience, getting an accurate understanding of these aspects is extremely hard and also extremely important. How do you get around this? Because this has to come before any architecture.

In a world with infinite labor power, the solution would be to simply do it, and then check where you fucked up with your unknown assumptions, delete everything and start again with a better understanding. Obviously, this is never practical nor feasible in real life.

What do you think?

>>17854
>Speaking about software architecture, in my experience, software architecture tends to be defined very poorly due to a lack of knowledge of the domain and the impact of decisions down the road. Simply put, the nature of dependencies, the limitations of the technologies used, and requirements at the time of design are not known, so the architecture is completely bonkers, constantly coping for the actual requirements and limitations found while developing.

sadly, without a crystal ball, there will never be a solution to this 100%. However the right methodology can help. This is why I prefer attribute driven design to domain driven design.

In the case of DDD the problem is:

"I ask my developers to do what I think should be a simple thing and they say its hard because 'the system' is designed in a way which makes my change hard"

The solution is:

"Make developers design the system in the way that the business talks about the system. Then you wont have this disconnect!"

However in ADD the architecture is the result of applying certain tactics and patterns to quality attribute targets. This means it isn't a reflection of or dependent on the domain a la "Conway's Law". DDD is great for the microservices philosophy of service-per-business-function but IMO a poor match for other things. ADD is a more general approach and better even if DDD is the hype right now.

The first book in:
>>17850
Explains ADD as well as the first pdf in thread.

>>17856
Interesting. I have never really got into software architecture beyond the bare basics. It sounds like a good thing to look up on to level up my career. Have you designed systems yourself in a corporate / business setting? If so, what was your experience, did you fuck up anywhere, what do you like/dislike about the process?
>"Make developers design the system in the way that the business talks about the system. Then you wont have this disconnect!"
This seems suspicious to me since DDD will inevitably mix the business understanding into the domain. An issue I have right now at work is that the business people don't even really understand the tool or business domain fully, so when they ask for features, it is left to us to figure out if it makes any sense. I've had this happen before with clients not knowing what they have and what they want. Of course this impacts the initial domain understanding and chaos ensues shortly after.

I don't see a way that Aspect Driven Design can side step these issues.

>>17857
Aspect -> Attribute *

>>17857
>>17858
I'm not an architect, just an engineer.

>An issue I have right now at work is that the business people don't even really understand the tool or business domain fully, so when they ask for features, it is left to us to figure out if it makes any sense. I've had this happen before with clients not knowing what they have and what they want. Of course this impacts the initial domain understanding and chaos ensues shortly after.

in that case I think requirements analysis is the step that needs more work. No architectural method can work with unclear requirements, and unfortunately clients are indeed known to change their minds about stuff. Requirements is sort of a different topic though which probably deserves its own thread.

Personally i'm glad i learned architecture, if only to do better in system design interviews. I've designed a few small systems in a work context but nothing at ""scale"".

Especially now in java shops they're starting to do all kinds of hardcore system design interviews that require you to know a myriad of on prem and cloud middleware/esb tools (muh apache artemis/apache camel/kafka/rabbitmq/mulesoft/aws kinesis) and integration+SOA patterns, I think the age of leetcode is passing and the age of "muh system design" is coming, esp. for non juniors.

In any case most people, be they architects, software engineers, or even related such as sdet/devops/etc, can benefit by learning some architecture. Its only learned by either years on the job (and even then only if you have relevant work experience, not maintaining one legacy app for example). OR you can take a shortcut and read some of the books ITT and level up without having to spend 25 years working on different systems.

IMO its sort of the missing link in software development education, unfortunately most CS programs(undergrad or grad) don't teach it and most undergrad SE programs (that exist) don't include it either. It's generally only taught in advanced degrees in SE (at least in the US), which is a shame because its literally useful for every software engineer and devops person.

PDF-REL is the original DDD book for anyone interested.

So is this all just for enterprise stuff? Would an embedded engineer get out anything of this at all?

>>17860
I'm not an embedded developer, so I can't speak to that, however the developers of ADD claim it to be a generally applicable technique:

>The software architecture community has created and evolved, over the course of decades, a body of generally accepted design principles that can guide us to create high-quality designs with predictable outcomes. For example, some well-documented design principles are oriented toward the achievement of specific quality attributes:

<§To help achieve high modifiability, aim for good modularity, which means high cohesion and low coupling.
>§To help achieve high availability, avoid having any single point of failure.
<§To help achieve scalability, avoid having any hard-coded limits for critical resources.
>§To help achieve security, limit the points of access to critical resources.
<§To help achieve testability, externalize state.
>§. . . and so forth.

<In each case, these principles have been evolved over decades of dealing with those quality attributes in practice. In addition, we have evolved reusable realizations of these abstract approaches in design and, eventually, in code. We call these reusable realizations design concepts, and they are the building blocks from which the structures that make up the architecture are created.

Some of the patterns around safety, such as Triple Modular Redundancy ( https://en.wikipedia.org/wiki/Triple_modular_redundancy ) seem more like things embedded devs would use than in web dev.

>>17849
Bruhhh this is so overwhelming. I had no idea this was expected in interviews. Now that I'm aiming for a higher title, I'll somehow need to cram this in a few days. 💀

>>17863

do it

ive been fucked on system design interviews before - i aced a take home project, OOP whiteboard shit, only to be totally fucked on a system design question.

They will ask you to design twitter on a whiteboard.

IF you don't have time forget the books and just go thru that github link

>>17864
OK, I will. Thanks dude. That repo is a life saver.

Not much of an update, regarding my systems design interview, but I've been cramming these videos:
https://www.youtube.com/@SystemDesignInterview

They're information dense, so I have to pay close attention. My fucking acquired ADHD is making studying extremely hard, but slowly I've been chipping away at concepts. I've already seen all the videos. Now I'm moving on to doing exercises from the git repo, and I'm also reading the company/department blog for pointers into what might be relevant. Kafka seems to be the bread and butter of large async microservice architectures in real world companies, as well as this one.

I think I have the basics down, but I'm still leagues away from being remotely "good" at this. I have one more day to study. Most of the concepts of the git repo I knew already, eg throughput vs latency, DNS, TCP vs UDP, etc. but the hard part is the actual designing of systems. Shit like configuration services (eg ZooKeeper), and redundancy techniques with stateless horizontal scaling backed by metadata services. It's these things I have never really worked with IRL and I've also never designed myself. Much less done them on the spot.

I've also been reading the first book here on and off: >>17851

After this road of discovery into the world of preemptive over-engineering, I now have a newfound respect for software architecture, if not at least to ace these interviews in the future, since it should be an easy interview if you memorize a handful of common architectures.

I'll update once again once I've done the interview.

>>17891
good luck anon

the guy who makes that channel is alex Xu who wrote the first book in the post you linked.

>>17898
kekek

>>17898
Is this what Elon Musk was talking about?

>>17910
yeah, pretty much. But if you explained it to your once-tech-literate grandfather and he explained it back to you.

>>17891
>>17892
Update. Predictably did like shit actually designing the system. It was a very naive approach, but I dropped more buzzwords than a clickbait tik tok video, but the engineer was pretty smart, so probably not impressed.

The hardest part was gathering requirements correctly. I stumbled through that and my requirements were shit. Then the design was half-baked, not thought through and mediocre. The engineer was cool and helped me along at least.

The most significant barrier to acing this was probably practicing. The problem was rather easy, tbh, and it didn't require any of the fancy shit you see on the design interview questions while studying. Still I struggled to design it. I was also nervous and figuratively shitting my pants all, so it could have been worse.

All things considered I'd say I did 6/10. At least my other interviews were strong so hopefully they balance out.

>>17849
>has different study plans depending on how much time you have left
You're going to die in seven days, why did you watch that cursed vhs tape anon???
>>17854
>In a world with infinite labor power, the solution would be to simply do it, and then check where you fucked up with your unknown assumptions, delete everything and start again with a better understanding. Obviously, this is never practical nor feasible in real life.
Feasibility is a bourgeois metric. In reality any rushed product is trash. Actual historical progress is only achieved through dialectical struggle through contradictions.

>>17913
GJ anon, especially on short notice

>>17915
Thanks :) much appreciated.

https://github.com/arpitbhardwaj/architecture-diagrams

repo containing a bunch of diagrams for common system design questions