system design

In my previous post Chopping the Monolith, I explained that some parts of a monolith are pretty stable and only the fast-changing parts are worth being 'chopped.' I turned the post into a talk and presented it at several conferences. I think it’s pretty well received; I believe it’s because most developers understand, or have direct experience, that microservices are not a good fit for traditional organizations, as per Conway’s Law. In the talk, I use an e-commerce webapp as a

In my previous blog post Chopping the monolith, I explained my stance on microservices and why it shouldn’t be your golden standard. However, I admitted that some parts of the codebase were less stable than others and had to change more frequently. I proposed 'chopping' these few parts to cope with this requirement while keeping the monolith intact. As Linus Torvalds once wrote: Talk is cheap, show me the code! I want to show how to do it within the scope of a small demo project to

If you attend conferences or read technical articles, you could think that microservices are the correct and only way to build a system at the moment. Despite some pushback from cooler heads, the default architecture is microservices. In this post, I’d like to argue why it’s wrong. I’ll first get back to the origin of microservices and the fundamental reason to use them. Then, I’ll describe why microservices don’t fit most organizations' structures. Afterward, I̵

During the pioneer area of the World Wide Web, the content was static. To serve it, a group of developers created a web server, which is now known as the Apache Web Server. The Apache Web Server is built around a module architecture. Developers created a module to run CGI scripts to add dynamic content to the lot. Users wrote early CGI scripts in Perl. After a while, it became evident that generating a complete HTML page from scratch was not the best way and that templating - providing an HTML