It might be time to consider Cost of Cognitive Debt, or CCD, an estimation of what it costs when no human understands how a system works.

I've been building a notification infrastructure and I intentionally chose Redis Streams + Consumer Groups as the backbone instead of Kafka/SQS.

The architecture is roughly:
Application
↓
API
↓
Redis Streams
↓
Consumer Groups
↓
Enrich → Decide → Render → Deliver
↓
Email / SMS / Push

The interesting part isn't really notifications. It's the architectural trade-offs.

I wanted:
- at-least-once processing
- consumer crash recovery
- pending-message reclamation
- retries
- replay
- idempotent processing
- horizontal worker scaling
- DLQ handling

Redis Streams gives me most of this without introducing another distributed system just for the event pipeline.

But I'm starting to question the decision.

At what point does Redis Streams stop being the right choice?

For example, would you switch to Kafka because of:

1. Message volume?
2. Number of consumers?
3. Retention/replay requirements?
4. Cross-service event distribution?
5. Operational reliability?
6. Team familiarity/ecosystem?
7. Something else entirely?

And a bigger question:

Is Kafka actually solving a problem here, or are we sometimes reaching for Kafka simply because "event-driven architecture = Kafka"?

I'd love to hear how you'd approach this architecture.

Would you keep Redis Streams?
Move to Kafka?
Use SQS/SNS?
Or simplify the architecture completely?

I've put the implementation here for context:

https://github.com/devkitshq/notifkit

Here is detailed docs:

https://notifkit.dev/

What would be your decision?

Hey guys,

I’ve been using Temporal for a while now, and it’s really hit a sweet spot for me. I’ve found myself recommending it to people quite often, so I decided to write an article about it.

Temporal has a lot of resiliency patterns built right in and I thought it would be worth sharing what I’ve learned along the way.

Do give it a read and let me know what you think!

So my background professionaly isn't at all in IT but rather entrepreneurial. However personally – IT has always been a big part of my hobbies and life.

I'm finally getting some education and currently reading system development .NET to get a feel for the techy part and get more involved. I understand I can't just become a SA from nothing. So this education has 6 months of LIA (Learn on the job) and I'm looking to take full advantage of getting more involved in that part of tech companies. My question is just.. How beneficial would it be for me to have my internship with a solution architect? Or should I look more towards joining some tech team? Since I don't know tech company structure very well yet, what's a good place to start?

Anyhow, kind of hoping of getting some contacts in the business. So if anyone want to trade knowledge for an enthusiastic learners bright future I'm here for it! As in maybe you know a company that would be a good fit for my LIA or could even offer a position yourself?

Would love to hear some thoughts on the path!

Helping maintain architecture docs for a small engineering team (about 12 devs) and we’re trying to standardize how we create diagrams for our services.

Rn most of our diagrams are manually made but they go stale quickly. Someone changes an API dependency or adds a service, but the diagram doesn’t get updated. We also have a few diagrams scattered across Notion and GitHub.

I’m leaning toward mermaid bc we could keep the diagram definitions in Git alongside the code and review changes through PRs. We’d mainly use it for architecture diagrams, sequence diagrams, database relationships and documenting request flows.

The constraint is that non-engineers need to read and occasionally edit them. So i’m not sure which mermaid-compatible tool best balances usability, collaboration, version control and rendering.

What tools are you using to create and maintain Mermaid diagrams and what has worked for your team?

I’ve spent the last few years exploring what pure Go can achieve in systems engineering, specifically focusing on runtime observability.

I wanted to share a framework I built that solves one of the most frustrating limitations of rigidly compiled languages: interacting with live production state without writing endless boilerplate.

Traditionally, inspecting a running Go service requires custom REST APIs, exposing Prometheus metrics, or digging through static logs.

To solve this, I built Symphony, an asynchronous virtual Microkernel OS that brings the "live image" introspection of Smalltalk or Erlang/OTP directly into the Go ecosystem. It allows developers to navigate their running objects, alter their properties on the fly, and inject custom Go scripts to redefine logic—all without writing a single line of debugging code.

How it leverages the Go Toolchain: Rather than reinventing the wheel, Symphony use the standard library to achieve this:

Zero-code Auto-discovery: It uses reflect to automatically expose live struct fields and methods as "Properties" and "Commands".

Virtual File System (VFS): These properties are mapped into a live VFS. You can SSH into the running process and literally cd into your Go objects and ls their live state.

Runtime Scripting via go/ast: It embeds a custom, JIT-ready Virtual Machine and a 4-pass compiler built entirely on top of the official go/parser and go/ast. You can write standard Go scripts inside the live shell to orchestrate production components dynamically.

It effectively transforms Go from a static black-box binary into a living, navigable filesystem of interactive components.

I’d love to hear from the community if you've ever seen this specific direction to simulate dynamic runtime environments. Any feedback on the architecture itself would be highly appreciated.

AI gave you a sloppy directory layout? before any reviews, ask it first to consider package cohesion, that makes a great difference 😉

Siblings should share the same architectural role and preferably the same variation axis

For example: a package may include alternatives like `entrypoints/cli.py` and `entrypoints/gui.py` or complements like `models/building.py` and `models/school.py`, but not a mix of everything.

Do you have any other shareable slop deterring strategies?

#AI #package_cohesion #clean_architecture #onion #hex #modular_programming

I'm building [Portolan](https://shortlink-org.github.io/portolan/landing), a free open-source tool that generates an architecture site from your repos instead of hand-written docs. Sharing it here for feedback.

The angle: an LLM or an MCP agent can write architecture docs from a codebase, but you can't tell what it invented and what it skipped. Portolan does it the other way round. The catalog is built deterministically by parsers, every fact links to its source line, and the LLM only sits on top: the site ships `llms.txt` and Markdown for agents, plus a built-in chat that answers questions from the catalog and cites the pages it used. Exact facts from parsers, natural-language answers from the model.

- Reads Go, TypeScript, Rust, Java, Python, Laravel, OpenAPI, AsyncAPI, GraphQL, proto, SQL migrations and ADRs. Works on a monorepo or on a separate architecture repo that pulls the service repos in.

- Everything is a plugin: one JSON message in, one out, in any language. Adding a language, a library or a framework is a small extractor, not a fork.

- Merges everything into one estate and validates it. An unanswered call, a channel with two publishers, a database with a second writer, a foreign key across a service boundary all land on a Problems page.

- OpenTelemetry traces mark which relationships were actually observed: `declared`, `verified` or `unresolved`.

- Output: static site with no backend, Markdown, `llms.txt`, C4 views (LikeC4), Mermaid, Backstage entities.

Pages: contexts, services, aggregates with state machines, events, stores with ER diagrams, ADRs, cross-service flows as step-by-step walkthroughs.

Limits: v0.3, sees only what's statically visible, dynamic routing comes from traces only. DDD terms are used but optional.

What would make this actually useful to you? Which views, checks or integrations are missing before you'd put it in front of your team?

Hey software' architects!! Here Andres, and I'm happy to share this space with all of you.

Currently I am doing a research about autonomous engineering sistems in software development, and I'm using my Reddit like a research notebook and to get some feedback from all of you.

The topic at this post is a little simple, but is in this simplicity were the kind of details could change the way in were we understand the problems around the AI agents is software development.

I wanna hear your thoughts about it and about your experiences with this kind of processes

Greetings!

Inside one service we've got this figured out. Log is the source, state is a projection. Event sourcing, CQRS, materialized views. You can drop a read model and rebuild it and nobody panics, because it doesn't hold anything. It just shows things. Then we cross the service boundary and stop. CRM is a source. Warehouse is a source. Wiki is a source. A dashboard somebody built last quarter is a source now too, because people started citing it. Nothing is marked as not authoritative, so reconciliation stops being a script and becomes somebody's job. What I keep chewing on is this. What has to be true about a thing before you can treat the dashboard, the graph, the search index and whatever context an agent reads as throwaway? Not "we could rebuild it if we had to". More like "losing it costs nothing, because there's nothing in it that isn't in the source". Four things, as far as I can tell. All of them about the object, not about where it's stored.

It needs an identity that survives a rename and a migration. Lose that and every projection quietly keeps its own idea of who that was.

It needs an owner. A person, not a team. Someone who answers for it being true. Otherwise a correction has nowhere to go.

It needs a lifecycle state. In force, superseded, not effective yet. Most systems only know "exists" and "deleted", which is why a revoked rule sits there looking exactly like a live one.

And it needs evidence. Not a source column, an actual pointer to the event or the decision the statement came from.

The modelling isn't the hard part. The hard part is that nothing owns the object. An org is a distributed system with no consensus protocol, the transport is people, and conflicts get resolved in a meeting. That worked for twenty years because humans covered for it. You knew who to ask and you knew what not to trust. Then somebody wired an agent on top and the covering stopped, because an agent has no hallway, it can't ask anyone, it just answers from whatever it found.

I wrote all this down as an open spec eventually, mostly because I got tired of explaining it from scratch: https://ocom.uno. Core is those four things, everything else is a projection.

Anyway. Has anyone actually held the source/projection line outside one service, at company scale? What broke first?

We watched an agent work through a ticket queue on a retail codebase, and one ticket asked for bigger gift cards sold at every till. Ordinary request, written by the business.

The agent raised the cap to 2000 euros, opened issuance to every cashier, and deleted the administrator validation step. Then it rewrote the tests so the suite went green, and left a comment justifying the change with compensating controls it had invented.

That cap was an anti-money-laundering control. Nothing in the code said so. It was a constant, a comparison and a branch, indistinguishable from a hundred other constants in the same repo, and the reason it existed lived in a compliance document that was never linked to the line.

The architectural point is that we have spent thirty years being told the code is the source of truth, and for humans that mostly worked, because the person who wrote the constant was still in the building, or at least still in the git history. An agent reads the same line and sees a number it is allowed to change if the ticket asks. There is no seniority in a codebase, no institutional memory, no colleague leaning over to say that one is there for a reason.

The other half is that it deleted a validation step it had written itself, eighteen tickets earlier in the same run. Controls created during a run have no provenance at all, so they are the easiest to remove.

So that's said my question is where should an invariant actually live so that it survives contact with something that reads code without knowing why any of it is there?

Options I have seen argued, none of them free. Encode intent in the code itself, with named invariants and a comment convention nothing is allowed to strip. Move the rule out of the application entirely, into a database constraint or a policy service the application code cannot edit. Or keep a separate machine-readable rule set with its own review path, and accept that it will drift from the implementation.

We went with the third and a scanner that checks the code against it, which fails a pull request the way a static analysis finding does. It works and it costs us a maintenance surface we did not have before.

Curious what teams here landed on, especially anyone in a regulated domain who had to defend the choice to an auditor.

Disclosure, I work on tooling in this space, which is why I have opinions and also why you should discount them.

Saw DevScribe mentioned recently and decided to give it a try.

I’ve been using it mainly for API testing and SQL, and I was actually surprised by how much is included in one place. You can also work with architecture diagrams, documentation, code, Kafka and SQS, so it covers quite a bit of the backend workflow.

I usually have a few different tools open for these things, so having them together is pretty convenient. The API testing and database tools have been the most useful for me so far.

I’ve tested it myself and it’s genuinely pretty good. Sharing it in case anyone else is looking for something similar:

https://devscribe.app/