Architecture

Cache invalidation is often said to be a hard problem to solve. I don’t think this is true in the context of software systems. Regardless of which caching strategies you use (Write-Through or Cache Aside), the key is to have well-defined boundaries. Other boundaries cannot be modifying data within another boundary directly at the database level. They must access it via the exposed API that forces cache invalidation or updating. Cache Invalidation doesn’t need to be a difficult problem. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that… Read More »Cache invalidation isn’t a hard problem

Common advice is to abstract dependencies. Often this is because people have been burned by depending directly upon 3rd party dependencies that they are highly coupled to. If they need to change the dependency, which they are highly coupled with, it can be pretty painful. This is why people say to create an abstraction layer around any dependency to isolate it so that your application code is coupled to yourself rather than a 3rd party. While this is generally true, it depends, and you don’t want to create an abstraction that is more work in the short and long run… Read More »When NOT to write an Abstraction Layer

If you’re developing a Monolith or using a Monolithic Architecture doesn’t mean it needs to be a big ball of mud. Most people equate a Monolith with a Big Ball of Mud because it’s highly coupled and difficult to change. However, you can combat it by defining strict boundaries and logically decoupling those boundaries and the data that each boundary owns. To go even further you can loosely couple by leveraging asynchronous messaging between boundaries. Does this sound familiar? Like Microservices where each service has its defined capabilities and database? YouTube Check out my YouTube channel where I post all kinds of… Read More »Long live the Monolith! Monolithic Architecture != Big Ball of Mud