Yes an external cache is definitely faster. That said does your application need the extra complexity? Is the caching in database really the bottleneck? If not, the question of the external cache is still open.

I don't think it's always unfolding exactly like this but there's some truth to that. Most projects see a "let's rewrite it in X" phase, this is rarely the best outcome.

Databases do improve and provide more "cache like" features, but such caches are still needed for the time being.

A short and to the point reminder on how to manage properly a "layer cake" architecture.

Good reminder of this important but imperfect guide to software design. There is some ambiguity on what "simplest" actually means. Still it helps keeping in mind that simple is rarely easy to find.

Ever wondered about how Windows 3 was architectured? This is an interesting read. It was really complex though, you can really tell it's in the middle of several transitions.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

Indeed, let's not fall for the marketing. It's better to write less code if it's enough to solve actual problems.

A good debunk of that claim we sometime see. Of course the tests need to be designed and you need to have good architecture blueprints to follow, otherwise you'll be in trouble... TDD or not.

Observability is indeed not necessarily easy to fit into a code base. Here is a potential approach to make it easier. I wouldn't use it on a project where we're only logging, but once you add metrics to the mix, this kind of probes can be worthwhile.

This is a good list of guidelines to produce a service which is less of a pain to test locally, deploy and operate. Of course, don't take everything at face value (not all of it aged well) but it's a good source for inspiration.

Or why you should know why you're picking a new tech stack... or not. Don't just blindly follow fashions.

When you realize TDD is about units of behavior... then you can see what can be iterative and what can't in your process. In other word, what is dictated by the problem domain is iterative, what is dictated by system architecture is not. Luckily, the latter is often related to the user experience you're aiming for.

Or why the microservice cargo cult which has been going on for a while now infuriates me. It totally ignores the complexity it brings.

Good insight into why Dropbox rewrote its sync engine for desktop clients.

It's likely the best explanation of the YAGNI acronym I know. Explains quite well when it applies or not.

A talk from Casey Muratori who is pushing his ideas on software architecture. This one is very interesting on the long history detour it does. Shows well how we keep rediscovering stuff which sometimes go back to the early times of computer science.

And it's not necessarily a problem. It all depends on the goal and context of the API you're building.

And one more... it's clearly driven by an architecture pattern used by all vendors. They need to get their acts together to change this.

This is indeed a metaphor which should be more common in enterprise software.