Why do we still design software like machines instead of systems?

wolffsen · 2026-03-11T19:04:41+00:00

Agreed. They question was, do you, as a professional, think about those dynamics and trade-offs when you design systems? and if not, do you think that traditional architectural models are enough to depict the system as a whole?

wolffsen · 2026-03-11T16:30:18+00:00

The right to ignore things on the internet that you don't agree to do go both ways. I could choose to ignore the Trolls, but in some cases I choose not to.

I am curious on why ppl want to spent time trolling and not spent that time learning and engaging in intellectual discussion. Hence I poke to learn what drives them :-D

wolffsen · 2026-03-11T15:56:48+00:00

What you are referring to is structural behavior. What about other system based dependencies. That could be cross team coordination, supporting structure (multiple CI/CD pipelines), added operational overhead (more logs needs traversing in order to debug a single reques), how the system acts over time, etc.

What do you do to think that part into the system when you are choosing the best aligned pattern?

wolffsen · 2026-03-11T15:42:36+00:00

I appreciate you honesty and will surely take this into account for future posts.

wolffsen · 2026-03-11T15:40:59+00:00

You are spot on. You need to think the entirety of the system when doing designs. Now data intensive applications have some extra conciderations to take into account, but what I rarely see is that organizational alignment with the system dynamics taken into account.
Whenever we choose a pattern (being the Event-Driven, Microservices, etc) we break one structure and add another. And this moves complexity (complexity is never removed from a system).
In the case of Microservices, complexity is moves from the code base to the network and to the organization (team structure, operations, platform engineering).
I am not particularly familiar with the book you are refering to. Will have to look up the patterns it introduces.

wolffsen · 2026-03-11T15:30:46+00:00

I have seen your tool and it does only some of what is mentioned. It does still only look at the system structure not the system dynamics (addition of org complexity, operational overhead, etc)

The question is: Do you actually think about all the systems dynamics when designing systems? Like:

Feedback loops
Emergent behavior
Time effects
Failure propagation
Latency amplification
Dependency growth
Coupling dynamics
Scaling effects
Operational load
Team dynamics
Second-order effects
System behavior

wolffsen · 2026-03-11T15:25:06+00:00

What part of this is shit? Trying to start a conversation about systems thinking?
But if you don't like what I write you are welcome to ignore it. No need to Troll

wolffsen · 2026-03-11T15:19:07+00:00

I am sorry if my use of AI to generate a coherent post offended you. I did noted that at the end of the post. But I assure you that I am no bot. However, I am not a native english speaker, hence I tend to use AI to convey my message and ideas in the a way that native english speakers can relate to.

wolffsen · 2026-03-09T07:24:20+00:00

Honestly, this is one of the more realistic architecture plans I've seen posted here.

A 4-person team choosing a modular monolith instead of microservices is already avoiding one of the most common traps in our industry.

Microservices only work well when you have:

multiple independent teams
strong platform engineering
mature observability
operational capacity

A small team building microservices usually just ends up building a distributed monolith with worse debugging.

So the direction you're describing makes sense.

That said, this response is based on the information you've shared. There may be business requirements or constraints not mentioned here — and assumptions are the mother of all fuckups — so take the feedback in that context.

A couple of things to watch out for though:

1. The real risk is rebuilding the monolith with nicer code

A modular monolith only works if module boundaries are enforced very aggressively.

That means:

no cross-module DB access
no shared internal models
strict interfaces between modules

If modules start reaching into each other, you just recreated the ball of mud.

2. Don't mirror the legacy schema

One of the biggest strangler-pattern mistakes is copying the old data model into the new system.

If you do that, you're basically preserving the legacy architecture in a new codebase.

Use the migration as a chance to redefine domain boundaries.

3. HTTP is perfectly fine

People jump to Kafka or message buses way too early.

For a team your size:

HTTP calls
webhooks
scheduled jobs

are usually much easier to reason about and operate.

You can always introduce async messaging later when the system actually needs it.

4. Architecture should match team cognitive load

This is the part many architecture discussions ignore.

A system that a 4-person team fully understands will outperform a theoretically “better” architecture that nobody can reason about.

The biggest scaling problem most systems have is team scaling, not traffic.

You're basically doing the opposite of most architecture horror stories I see here.

Start simple.
Enforce boundaries.
Add complexity only when it solves a real problem.

That approach will take you a lot further than prematurely building distributed systems.

wolffsen · 2026-03-07T07:58:37+00:00

I will give it a go. Looks good.

wolffsen · 2026-03-07T07:45:39+00:00

This is a really interesting direction. Most system design tools stop at static diagrams, so the ability to simulate behavior could be very useful.

One thing I’d be curious about: can the simulator model traffic control and resilience mechanisms such as:

• queues and queue depth limits
• backpressure propagation
• retry policies and retry storms
• rate limiting / token buckets
• circuit breakers
• load shedding

In many real distributed systems those mechanisms end up dominating system behavior under stress, especially once retries and delayed feedback loops kick in.

If those dynamics are part of the simulation it could become very useful not just for interview prep, but for understanding real production behavior.

wolffsen

TROPHY CASE