PHP at Scale #5
Welcome to the fifth edition of PHP at Scale. I am diving deep into the principles, best practices, and practical lessons learned from scaling PHP projects — not only performance-wise but also code quality and maintainability.
🎄Christmas is just around the corner, and the end of the year is typically quite busy for most of us.
So, with this edition, I would like to wish you all a Merry Christmas and a Happy New Year. Unlike the previous editions, I won’t focus on any particular topic this time; I will just share some good articles I came across recently, or I think are relevant to the topic covered in another article ;)
Team structure: communication and topologies in legacy software projects
I first came across Conway’s Law a couple of years ago, and I have to admit I think about it quite often. Although we usually work with smaller companies, that do not have that many departments and work with a flat communication structure, it is still worth keeping it in mind. It is a nice tool to think about the top-level split of your application. Of course, this rule on its own does not fix everything, but Leszek goes through some tools/approaches that can help to organize the code well.
One comment from my side here: it’s very useful to keep Conway’s Law in mind when discussing microservices. I typically hear people discussing microservices as the way to scale. And that’s true, microservices are a good solution to scale the team, not software ;)
It’s very easy to jump into the decision of “just adding a queue”. It always makes sense when we make the decision, but if we do not have too much experience with it, we might fall into the trap of underestimating potential problems. Each approach and each queueing system comes with its issues. The outbox pattern is something worth knowing for sure. I know the idea of storing messages in a database might seem bad at first glance, but it is not as bad as you might think :)
The DB storage also helps with some other issues, that I will touch on in the next article. And when we consider that Postgres listen/notify works quite well, it might change your view on the queueing.
Queueing in multi-tenant SaaS systems. How to ensure its fairness
Another underestimated complication that I can see is multi-tenancy. And as it comes in many flavours, also the issues differ from one to another implementation. One thing is common, no matter the approach you take, it will almost for sure come with some difficulties. We talked already about how queues can be challenging, but multi-tenant queues are even more complicated than that ;) For that reason, I’ve described a couple of approaches in my article some time ago.
Tenancy models for a multi-tenant solution
Most of the different SaaS products we consulted in the past used the approach of separate DB per tenant or had all tenants in one database. The solution does not always have to be just black or white, and there are different drivers to be considered when choosing the approach.
As a complement to the article, I recommend exploring the three architectural models: silo, pool, and bridge.
SaaS Lens - core isolation concepts
Maybe not an article, but a source of knowledge that is good to know exists. I usually find AWS/Microsoft content to focus on much bigger projects compared to what we do daily. But it is still worth to read the provided articles/white papers. Just good to keep in mind the (potential) size difference, and adjust the knowledge to your case.
What I wanted to bring up with those two articles is that you don’t always need to jump straight to the silo or bridge mode, yet the pool also comes with its issues. And for sure, you should not jump into using ready libraries that provide multi-tenancy in your project using some magic without understanding the key architecture decisions and options.
Octoverse: AI leads Python to top language as the number of global developers surges
It's not really PHP or scaling things related, but it's a nice wrap-up of the year.
It is a bit worrying that PHP lost one place, but with all the effort put into both the language and the ecosystem, I believe it will be on the rise in the upcoming years✌️.
Why is this newsletter for me?
If you are passionate about well-crafted software products and despise poor software design, this newsletter is for you! With a focus on mature PHP usage, best practices, and effective tools, you'll gain valuable insights and techniques to enhance your PHP projects and keep your skills up to date.
I hope this edition of PHP at Scale is informative and inspiring. I aim to provide the tools and knowledge you need to excel in your PHP development journey. As always, I welcome your feedback and suggestions for future topics. Stay tuned for more insights, tips, and best practices in our upcoming issues.
May thy software be mature!