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.

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

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?

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.

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?

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?

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?

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.

We've got a team of 11 software architects spread across platform, backend, cloud and security. Most days are architecture reviews, RFCs and whiteboard sessions, so everyone knows each other professionally, but not much beyond that.

Recently, we tried the happy hours and virtual trivia and attendance was decent, but nothing really carried into day-to-day collaboration. What helped was running architecture katas where mixed teams solved the same scaling problem and compared tradeoffs afterward. The discussions became noticeably more constructive in later design reviews.

Still, a few quieter architects rarely participate unless it's technical. Looking for team bonding ideas that feel natural, not like HR homework.

I’m digging deep into data modeling trade-offs (specifically Document DBs vs Relational/Postgres).

Marketing materials and books always list the usual MongoDB wins:

1. No-translation pipeline
2. Flexible schema (Zerodowntime feature additions without DB migrations)
3. Single-document atomic writes
4. Built-in horizontal sharding

But in practice, most backend engineers I talk to favor "Default to Postgres".

When applications grow, handling schema evolution in application code (Schema-on-Read with if/else or defaults) creates its own maintenance nightmare/code rot.

On the flip side, Postgres handles online schema changes pretty well nowadays, and JSONB covers many flexible-schema edge cases anyway.

My question for senior/staff engineers running production systems:

• Beyond early-stage startups that just want to build an MVP quickly, when did NoSQL genuinely save your architecture compared to a modern Postgres setup?
• How do you weigh the Operational Overhead of SQL migrations (and potential lock risks at scale) against the Application Code Complexity of maintaining un-migrated NoSQL documents?

Thanks!

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?

Since 2023 I have maintained a Go template that implements the tactical patterns end to end: validated entities, a Money value object, aggregates referenced by ID, repositories owned by the domain, CQRS-style command/query split, domain events via a transactional outbox, and race-safe idempotent commands. Everything is tested, including integration tests against a real Postgres database. Go is not always ideal for DDD, but I have shown some concepts as simply as possible.

I recently wrote a tutorial around it: https://sklinkert.github.io/go-ddd/

Code: https://github.com/sklinkert/go-ddd

It's one bounded context on purpose (teaching scope), and the FAQ is honest about when DDD is overkill. Curious how this community judges the aggregate boundaries and the trade-offs. The r/golang thread mostly debated folder structure, I'd rather argue about the model :)

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 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