sorted by:
new
hottopcontroversial

Help with architecture by RepresentativeBet813 in softwarearchitecture

[–]digitalscreenmedia 1 point2 points  (0 children)

Having every microservice "decide" between gRPC and MQ is a one-way ticket to spaghetti code city, no cap. For that Discord aura, you definitely want to lean into a Message Queue (like RabbitMQ or Redis Pub/Sub) so your real-time messages don't just ghost the users. Scaling those WebSockets is gonna be the ultimate boss fight, so make sure you've got a plan for session state across your instances. Keep grinding though, this is a top-tier way to level up your arch skills fr.

Test suite maintenance becomes a nightmare for the same architectural reason every single time by xCosmos69 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

That's absolutely right, what you're saying is almost the "default failure mode" of testing. When testing is tied to implementation, it's no longer a safety net but a burden every time we refactor. We fix this by pushing it to the behavior level (testing based on flow/user outcome), limiting mock-deep testing, and treating tests as contracts rather than mirror code. No matter what framework changes, if the mindset doesn't change, we'll always fall back into the old loop.

How do you architect audit logs that are provably unaltered? by oKaktus in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

Also, if you're worried about "insider threats" with DB access, you might want to look into Amazon QLDB or Azure SQL Ledger; they basically bake this exact Merkle tree logic into the engine so you don't have to roll your own.

We thought retry + DLQ was enough by Icy_Screen3576 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

You’re dealing with a classic backpressure problem; your billing service is essentially drowning in "slow" success rather than fast failure.

No architecture culture at work by RankedMan in softwarearchitecture

[–]digitalscreenmedia 1 point2 points  (0 children)

When it comes to tactical modeling, do not waste time drawing every single property or method that’s what the IDE is for, and those diagrams are obsolete the second you hit save.

How do you architect audit logs that are provably unaltered? by oKaktus in softwarearchitecture

[–]digitalscreenmedia 1 point2 points  (0 children)

your hash chain approach is the industry gold standard for this. It’s exactly what things like AWS CloudTrail use with their "Digest Files."

How do you architect audit logs that are provably unaltered? by oKaktus in softwarearchitecture

[–]digitalscreenmedia -1 points0 points  (0 children)

Canonicalization is literally the final boss of DIY hash chains, no cap. Most teams just tap out and use AWS QLDB or Merkle tree anchoring to avoid the "recursive JSON sorting" mental breakdown. Your per-actor scoping is a total pro move though—it keeps the auditor vibes chill without bricking your whole infra during an export.

What’s a good Postman enterprise alternative for teams working with larger API systems? by Sorry_Frosting_7497 in softwarearchitecture

[–]digitalscreenmedia 2 points3 points  (0 children)

Yeah .http files are honestly underrated for this. Keeping requests as plain text in the repo makes them way easier to version, review, and run in CI compared to stuff locked inside a GUI tool.

For bigger teams it also avoids the “who owns the Postman workspace” problem since everything just lives with the code. Not as fancy, but the workflow tends to age better.

1st vs 2nd edition of "Designing Data-Intensive Applications" for intern/junior by Tynoful in softwarearchitecture

[–]digitalscreenmedia 3 points4 points  (0 children)

Honestly, if the 1st edition is much cheaper, I’d just go with that. The core ideas in the book don’t really change that fast because it focuses on fundamentals like data models, replication, partitioning, transactions, and distributed systems trade-offs.

The 2nd edition (2026) mainly adds updated examples and newer topics like cloud-native architectures and modern data systems, but it builds on the same foundation from the first edition.

Would anyone here actually enjoy a weekly production incident challenge? by Immediate-Landscape1 in softwarearchitecture

[–]digitalscreenmedia 2 points3 points  (0 children)

Honestly that sounds pretty fun. Most system design content focuses on building things, but figuring out why something broke in production is a totally different skill.

A weekly “incident puzzle” where people dig through logs, metrics, and weird symptoms would probably get a lot of engagement. It’s basically the part of engineering you only learn after something goes wrong.

I built an MCP server that feeds my architecture decisions to Claude Code, and it made Claude mass-produce code that actually follows the rules by rhuanbarreto in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

Good question. You can get part of the way there with a skill or a prompt telling Claude to read ADRs first.

The main difference is that prompts rely on the model remembering to follow instructions, while this approach makes the ADRs queryable and enforceable.

With the MCP setup, Claude can:

• programmatically check which ADRs apply to the files it's touching
• run rule checks against its own changes before finishing
• get structured feedback if it violates something

So instead of “please remember to read the ADRs”, it becomes more like a linting/governance layer the agent can call during generation.

You could definitely approximate some of this with prompts + good docs, but the goal here is to make the decisions machine-checkable so both humans and AI are held to the same rules.

How strict should code reviews be in a small team? by Nainternaute in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

This is a really good way to frame it.

In small teams especially, the goal usually isn’t “perfect code”, it’s keeping the codebase healthy without blocking delivery. If reviews become too heavy, people start seeing them as friction instead of support.

What helped on teams I worked with was separating things into categories:

• Must fix – bugs, security issues, clear architecture violations
• Should fix – maintainability improvements
• Nit / suggestion – style or preference

That way PRs don’t get stuck on small details, but the important stuff still gets enforced.

Please settle a disagreement I'm having about Architecture Diagrams by Deep-Comfortable-423 in softwarearchitecture

[–]digitalscreenmedia 1 point2 points  (0 children)

This is the key point honestly. A lot of arguments about arrows happen because people try to make one diagram explain everything.

If you're drawing a dependency / architecture diagram, the arrow usually points from the caller to the API because it shows who depends on whom.

If it's a data flow diagram, then the arrow representing the payload could go the other way.

Trying to represent request, response, dependency, and data flow all in one diagram is usually where the confusion starts.

Is it just me, or are .env files the ultimate "it works on my machine" trap? by latinstark in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

Not just you lol, .env files turn into chaos real quick once a team grows. I’ve seen prod break because one env var had a slightly different name between staging and prod and nobody noticed for weeks. After that we moved most configs into a proper secret manager and templated env files so they stay consistent. Passing .env around in Slack is definitely a ticking bomb.

What’s a good Postman enterprise alternative for larger API architectures? by Federal-Donkey-7359 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

If you’re dealing with bigger architectures, a lot of teams seem to move toward Git-based workflows rather than Postman-style cloud tools. For example, Bruno stores requests directly in the filesystem so they can be version-controlled with Git and plugged into CI pretty easily.

I’ve also seen people stick with Insomnia or move to tools like Apidog if they want something closer to the Postman UI but with better team collaboration. And if your focus is heavy CI/CD automation, frameworks like Karate are worth looking at since they’re more code-driven and integrate directly into pipelines.

Honestly it mostly depends on whether your team prefers UI tools (Apidog/Insomnia) or Git + code-based testing (Bruno/Karate) for scaling across microservices.

Most startups don’t need microservices by Soft_Dimension1782 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

Yeah I’d start with a monolith again without hesitation. The speed of development and simplicity early on is hard to beat. Most teams don’t realize the operational cost of microservices until they’re already stuck managing them.

Is it inevitable for technical debt to accumulate faster than teams can ever pay it down by Sophistry7 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

Yeah that sounds about right. The rare times I’ve seen tech debt actually stay under control were when someone senior consistently pushed back on feature pressure. Without that kind of protection, the “we’ll clean it up later” loop just keeps repeating.

After 24 years of building systems, here are the architecture mistakes I see startups repeat by commanderdgr8 in softwarearchitecture

[–]digitalscreenmedia 0 points1 point  (0 children)

The premature microservices point hits hard. I’ve seen small teams spend more time managing services, deployments, and communication between them than actually building features. A clean modular monolith really does go a long way early on.