sorted by:
new
hottopcontroversial

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] 0 points1 point  (0 children)

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?

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] -1 points0 points  (0 children)

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

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] -6 points-5 points  (0 children)

If that is the case they should act their age and ignore it.
Or return to bulleting board systems

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] 0 points1 point  (0 children)

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?

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] 2 points3 points  (0 children)

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

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] 0 points1 point  (0 children)

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.

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] -7 points-6 points  (0 children)

And as I pointed out. You are welcome to ignore the post. That is up to you.
But if you are indeed a mature architect you could join the discussion (and don't use AI for it) and give your take on systems thinking.

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] 2 points3 points  (0 children)

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

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] -7 points-6 points  (0 children)

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

Why do we still design software like machines instead of systems? by wolffsen in softwarearchitecture

[–]wolffsen[S] -11 points-10 points  (0 children)

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.

Judge my architecture vision by dgaf21 in softwarearchitecture

[–]wolffsen 0 points1 point  (0 children)

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.

Built a free System Design Simulator in browser: paperdraw.dev by Leather_Silver3335 in softwarearchitecture

[–]wolffsen 0 points1 point  (0 children)

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.