I am sharing an essay I recently published on Trust . How human trust operates and how this translates or not wrt digital trust. Architecturally, there are a some pertinent considerations that I dive into. If you have the time and interesting in human to digital trust please have a read.

I'm building a permissions matrix where:

• Rows = permissions (organized as a hierarchical tree)
• Columns = user roles
• Each cell indicates whether a role has a given permission.

The UI requires the entire hierarchy to be visible at once (expanded by default), so traditional pagination isn't really an option. The frontend uses virtualization, so rendering performance is not the issue.

Let's say I have around 40 roles and 400 permissions, which means the UI needs to represent about 16,000 possible role/permission combinations

Is it considered acceptable for the backend to return the complete dataset in a single request if the client genuinely needs the whole matrix?

Or is this generally considered an anti-pattern?

I'm mainly interested in backend scalability:

• Memory usage
• Serialization costs
• Network transfer
• Response size
• Overall scalability as the number of roles and permissions grows

I'm curious what patterns you've seen in production systems for this type of UI.

Hello,

I have usually seen people recommend not creating foreign keys to partitioned tables and instead relying on application-level validation.

Personally, I think that's a horrible idea.
Once invalid references start leaking into the database, they're difficult to detect and even some system it is impossible to clean up.
No matter how many safeguards exist in the application, a future code change, migration, or overlooked edge case can still introduce inconsistent data.

My preferred approach is to keep an unpartitioned table that owns the IDs replica and use that as the foreign key target for related tables, while the partitioned table stores the actual data.

Has anyone else used this pattern? Are there other approaches that preserve referential integrity without introducing too much complexity?

Engineer for years but always felt a gap. I build things that work but I want to properly understand design and architecture, not just do it by instinct. Also feel a degree never hurts and will help professionally too.

Got accepted into a part-time online MSc in Software Architecture & Design while working full time. Anyone done something similar? Worth it?

What is your go-to setup for instrumenting analytics/telemetry?

At what point into a project is proper telemetry implemented?

Does observability tend to be implemented too soon, or too late? What are the side effects of mis-timing its implementation?

Architecture diagrams have two failure modes. Three boxes that say nothing, or a hairball of two thousand nodes that says everything at once, which is also nothing. Both get screenshotted for a deck and never opened again.

Neiither answers the question you actually have in a new repo, which is not "what connects to what". It is "where am I, and does this matter".

So I built the other thing. A map you zoom into

The whole repo is one card. Zoom in and it opens into layers, then folders, then files, then functions. It is continuous, like a map app going from country to street. No level dropdown, no reload, no re-layout between steps, so you never lose your place.

The key thing: you never look at the whole repo at once. At any level you see a handful of cards, and you dig deeper only where it matters. It is something you navigate, not one dense picture you stare at. And it is not drawn by hand. It is generated from the code and git history and stays current as you commit, so it cannot hallucinate a module or drift from reality.

What makes it readable:

Cards are sized by how the system runs, not by line count. Entry points, what everything routes through, what churns. The code you should look at first is physically the biggest thing on screen.

Each card carries a health dot, rolled up so a folder reflects everything inside it. You find the bad neighbourhood from orbit and then dive.

Edges only appear when you hover a box, and only that box's edges, curved around the other cards rather than through them. That single decision is most of the difference between a map and a hairball.

The performance answer, for anyone who assumes this dies at scale: you never draw the whole repo. Anything off screen or smaller than a couple of pixels is skipped, so a frame draws a few dozen cards whether the tree has 2,000 nodes or 10,000. Cost stops scaling with repo size, which was the point.

It is part of an open source tool I maintain called Repowise, AGPL, runs fully local. Gif is it mapping its own repo.

Link: https://github.com/repowise-dev/repowise

Edit: no, it's not just C4. C4 is four static diagrams you draw and maintain by hand. This is generated from code and git history, one continuous zoom, with card size from centrality and churn, plus co-change and health that C4 has no concept of

Edit 2: Thanks for all the feedback, the Structurizr DSL point came up enough that I am adding it as an export format, emitted as a model file you include from your own workspace so your views and styles stay yours and never get overwritten on re-index

I have a theory about how HirePro handles proctoring and wanted to know if anyone has looked into this before.

Does HirePro's screen-sharing feed capture screenshots only when JavaScript raises a flag (tab switch, focus loss, fullscreen exit, etc.), or does it capture screenshots continuously at around 1–2 FPS and analyze them for abnormalities?

Handling both webcam feeds and screen-recording feeds for 300+ students over a 1–2 hour assessment seems computationally expensive, so I'm curious how they scale this in practice.

I also inspected the HirePro browser extension and found that its code appears to primarily disable other extensions, re-enable them after the assessment, and report if any extensions are forcefully turned back on. I didn't find any webcam or screen-monitoring logic in the extension itself.

Has anyone analyzed HirePro's architecture or worked on a similar proctoring system? What is the most likely approach being used here?

Context:

Lately, I've been thinking a lot about how to improve as a developer. Because of this, I started talking to coworkers, book authors, highly experienced devs on Reddit, professors, and more. I reached the following conclusions, but I'd love to hear your thoughts. Keep in mind that the goal of this post is to see if I'm on the right track to level up as a professional.

What I learned from talking to others:

Every developer I spoke with followed a different learning path, and I never heard the same opinion twice. However, there is one thing everyone agrees on: practice is what matters most, far more than any theoretical resource. You need to actually work, question the "why" behind every decision, compare different solutions across different scenarios, and even put in extra hours of practice by building long-term personal projects. This is why I started working at quite a young age. Thanks to that, now that I'm almost graduated with a Computer Science degree, I already have several years of experience in the industry, where I've learned a lot.

This doesn't mean you shouldn't study, though. Personally, I'm just two courses away from graduating and I'm far from done studying, as I deeply believe that having a solid knowledge base helps you get much more out of your working hours.

My final conclusion:

While there doesn't seem to be an "ideal" learning path, I lean toward finishing my degree and supplementing it with extra knowledge in the area I'm currently most interested in: Software Architecture. That's why I look to get a high-level overview of different architectural patterns, software design patterns, solutions to common problems, etc., using resources that are easy to digest (like roadmap.sh, YouTube, courses, or books). The goal is to get familiar with the concepts, even if just superficially, so I know they exist.

If I ever need to apply a new architectural pattern that I haven't used before, I'll likely have to dive deeper into it at that moment—and that's totally fine, because that's the right time to do it. But I don't think it's important to read deeply into every existing pattern and concept from the start, because knowledge only sticks when you take it out of the theoretical framework and apply it to a project with real clients.

My question regarding this conclusion:

Does this approach of getting a high-level overview of concepts in my area of interest, and then diving deep only when I need to apply them, sound right to you? Or is it better to further strengthen my fundamentals first, keeping in mind that I've almost completed 5 years of university and have a couple of years of industry experience as a full-stack dev?

Released this recently for free, mini guide on Mermaid and free in-browser editor (with share capability from URL params) - all data local, no sign up required.

I am not talking about hypothetical but system designs that are highly abstract; they require DSL (domain-specific language), declarative schema manifest designs.

I have some people offering to buy off a platform I've built and they've been struggling to hire anyone. Note, I am not promoting what this org may want or want to do.

They've taken the codebase and fed to all the LLMs - Codex, Fable, Kimi, and they all come to the same conclusion - they need to hire 4-5 L6 engineers.

The individuals need to know platform architecture (not in the sense of infra) but building subsystems that are declarative schema driven. Hence, the walls of JSON data contracts. And to build compilers against those schemas. So technical grammar is fundamental. That takes people out completely when they see manifest generate everything -- UI, backend workers, etc and the first thought is configuration building.

The simplicity on the surface hides the complexity. The JDs attract ivory architects and very few people that have dsigned DSL. Focus is more on graph system than REST. And most people jump straight into feature implementation.

An analogy is you are building a factory that produces a run-time so end users can design their own demolition crash car inside a 3D gaming world. The cars all have their own physics, properties like speed, consumption, and properties like material structure that can handle a demolition derby crash.

The DSL creates the authoring, rendering and run-time. So hundreds of gamers can drive and crash into each other. The JSON schemas define their speed, crash, regen, and how they interact with each other. The DSL is the heart of everything -- from ops orchestration, handling users, to rendering the 3D models of the cars. That is the beauty of the design. Entirely manifest driven so there are no one-offs for a truck or a sports sedan. Add new materials like aluminum or carbon, no re-code needed. The DSL compiler builds it.

The above is just an analogy. Every LLM model calls this platform factory builder. Not to be confused with the GoF design pattern of factory class. And not to confuse DevOps of infra when they hear "platform." They also note the pitfalls of engineers who simply use LLM to work with the codebase without having the proper mental models. Thus the L6/L7 designation classification of the codebase.

But the goal is engineering teams that understand those DSL, the data contracts. Every LLM I've interacted with states, if they can read the JSONs in 15 seconds, that is the type of people you want on your team. Otherwise, it will be a struggle. Because it is "Think less of JSON parsing and more application compiler"

Note, this is a shipped product.

Been prototyping systems a lot lately and got tired of hand-drawing boxes in draw.io every time. Built a small tool: you type a system description, it streams out a real architecture diagram node-by-node as the LLM generates it (real cloud service icons, not generic shapes)

Still rough — no auth/persistence/multi-user yet, this is a prototyping tool not a product. Happy to share more or open it up if people are interested.

I built an LLM agent that talks to customers about casting molds, while a

deterministic geometry kernel (OpenCASCADE) does the actual computation

through a strict validated contract. Wrote up five concrete failures from

building it — including a kernel that reports success while returning

garbage, and why "retryable vs not" turned out to be an architecture

decision, not an error-message detail.

I am trying to learn modular monoliths and I want to use this auth solutions for repetitive use for my applications.

If I asked you to convert the repo linked, into monolithic patterns, how would you do it for app/.

Repo: https://github.com/auth0-blog/auth0-rbac-fga-fastapi

Cache invalidation is famously one of the hardest problems in computer science.

What is your absolute go-to strategy when you need strict consistency but cannot afford database latency?

Do you trust Write-Through, rely on short TTLs, or do you have a custom event-driven cache-busting mechanism that actually works? Drop your architecture patterns below!

One thing that has always bothered me about architecture documentation is that diagrams usually end up as static images.

Whenever the architecture changes, you have to export a new image and replace it everywhere it's used. After a few months, the documentation is usually out of date.

So I built a diagram editor with a different workflow.

• Create animated HLD (architecture) diagrams
• Drag and drop components like services, databases, APIs, Kafka, Redis, etc.
• Embed the diagram directly into documentation
• Edit the original diagram later, and every embedded version updates automatically

The goal was to make architecture documentation easier to maintain instead of constantly updating screenshots.

Multi-agent systems slow down fast when every agent waits on a central controller for instructions. That controller becomes a bottleneck and a single point of failure. An event mesh fixes this by letting agents trigger themselves the moment relevant data shows up, no controller required.

This shift changes how you design the whole system. Instead of asking "who calls this agent next," you ask "what event should wake it up." It's a small mental shift with big architectural consequences.

What Is an Event Mesh in a Multi-Agent System?

An event mesh is a network of event brokers that routes messages between agents in real time. Agents publish events when their work finishes. Other agents subscribe to the events they care about and react instantly.

Unlike a single message queue, a mesh spans multiple brokers and locations. Agents don't need to know who's listening. They just publish, and the mesh handles delivery. This decoupling is what makes self-triggering possible in the first place.

Why Let Agents Self-Trigger Instead of Using a Controller?

Self-triggering removes the bottleneck a central orchestrator creates. When agent A finishes a task, it publishes an event. Agent B picks it up on its own, without waiting for permission from anywhere else.

This cuts latency, since agents react the moment data is ready instead of waiting on a polling cycle. It also improves fault tolerance. If one agent goes down, others keep responding to events without the whole pipeline stalling.

The tradeoff is visibility. Without a controller, it gets harder to answer a simple question: what actually happened, and in what order.

Core Patterns for a Self-Triggering Agent Architecture

Three patterns matter most here. First, define clear event schemas. Every event needs a consistent shape, so any agent can parse it without guesswork.

Second, make agents idempotent. If an event fires twice, the agent should produce the same result both times. This protects you from duplicate processing when the mesh retries a delivery.

Third, scope your topics carefully. Broad topics create noisy agents that react to events they shouldn't touch. Narrow topics keep each agent focused on exactly the signal it needs.

Teams building this from scratch often end up wiring together separate tools for orchestration and messaging. A platform built for multi-agent systems, with real-time pub/sub baked in, removes that integration work and lets you focus on the event logic itself.

Common Pitfalls When Agents Trigger Each Other

The biggest risk is the feedback loop. Agent A triggers agent B, which publishes an event that triggers agent A again. Without a circuit breaker, this loop runs until something breaks.

Race conditions are the second risk. If two agents subscribe to the same event and both write to shared state, you get conflicting updates. Design each agent to own a clear, separate piece of state.

Cascading failures round out the list. One slow agent can back up an entire chain of dependent events. Set timeouts on every agent, and let the mesh route around agents that stop responding.

How to Monitor and Trace Self-Triggering Agents

Once agents trigger themselves, you lose the simple call stack a controller gives you for free. You need monitoring and observability built for event chains, not just single requests.

Traceability matters even more here. When five agents react to one event in sequence, you need to follow that chain end to end, especially when debugging a failure three hops downstream. A platform with built-in traceability and observability lets you see the full event chain in one place, instead of piecing it together from five separate logs.

FAQ

What's the difference between an event mesh and a message queue?
A message queue moves messages between two points. An event mesh connects many brokers and lets any agent publish or subscribe across the whole network, not just one queue.

Do self-triggering agents need a central coordinator at all?
Not for routing events, but you still want a way to monitor the system. A lightweight observability layer, not a controller, keeps you aware of what's happening without adding a bottleneck.

How do you prevent infinite trigger loops between agents?
Add a circuit breaker that tracks how many times an event chain has looped. Once it hits a limit, the mesh stops the chain and flags it for review.

Is an event mesh harder to debug than a request-response system?
It can be, since there's no single call stack to follow. Good tracing across the whole event chain closes most of that gap.