This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.
Friendly reminder that the answer is "no". You don't want to just rewrite everything, it's not just a syntactical translation, it's a long project and at best you tackle critical components.
This is a good reference on how to write design documents. It's not as easy as it sounds sometimes, and this guide contains good tips.
It's definitely easier not having to scale at all. Which is what you get when you design for local first / client side.
Queues are not magic. If they're unbounded you're in for a world of pain as load increases.
A good primer on the main architecture traits of transformer models.
Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.
Which means simpler models: and this is fine for most use! It's also easier to have more ethical options with the smaller and more specialised models. Let's not forget they exist even though the big industrial complex would like people to forget.
Architecture work is not only technical, you need processes to put the architecture of a project in place. That said, you can make things easier with standards to smooth the path toward the preferred types of architectures in your organisation.
Indeed, architecture work is not only technical (what is really?). You definitely need to account for the organisation and the process to actually put the architecture in place. It's not just about having pretty pictures.
A good primer about design documents. What's nice about this one is the focus on the process rather than the form of the document. Indeed what matters is the shared understanding and making sure the right decision is made.
Shows the problem with layer cakes in applications or how you might want to go toward onion architectures.
Are you sure your understand how your reverse proxy works and the impacts it can have in production?
Lots of good insights in here. Of course YMMV and some definitely depends on your context. That's a lot of dimensions to keep in mind though.
A very good talk which walks you through how to move from object-oriented design to data-oriented design. Shows quite well how you must shift your thinking and the difficulties you might encounter with data-oriented designs. I appreciate a lot that it's not just throwing object-oriented design out of the window, indeed you have to pick and choose depending on the problem space. Also it's interesting to see how C++26 reflection might make some of this easier.
Interesting model for bringing architectural and organisational changes. This is indeed at least in part political games... so you need some political capital to spend.
No, modularity doesn't imply micro services... You don't need a process and network barrier between your modules. This long post does a good job going through the various architecture options we have.
Interesting essay looking at how systems evolve their schemas over time. We're generally ill-equipped to deal with it and this presents options and ideas to that effect. Of course, the more precise you want to be the more complexity you'll have to deal with.
Clearly not a style which works for any and every applications. Still, it's definitely a good thing to aim towards such an architecture. It brings really nice properties in terms of testability and safety.
Still young and pretty much a one man show. This could turn into a nice tool to use C4 more productively.