PHP at Scale #9
Welcome to the ninth 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.
Today I will get to the roots of this newsletter, and discuss a topic that might help you scale, or easily bury your scaling efforts. Let’s discuss software architecture a bit. And before you decide you are a developer, not an architect, let me ensure you everyone will benefit from some basic software architecture knowledge :)
The idea for this topic came from a Reddit discussion, where an interesting question was raised: how to work on an MVP of a product and then scale it if required.
Not sure if I will be able to answer this question, but let me first introduce some helpful content.
Oskar does not fully answer the question of what Architecture Drivers are, but it is a nice (and short!) article to kick off. It already mentions some constraints and will give you some food for thought.
Architectural Drivers in Modern Software Architecture
A longer article, that quite broadly, discusses what Architectural Drivers are. It also goes a bit deeper into the flow of discussing drivers with business. If I got 1$ each time business people draft unrealistic requirements the first time you ask them, I would be a millionaire. Jokes aside, if you ask your client about availability — it will always be 24/7, and if you ask about the traffic to handle — it will always be huge, performance — always has to be “fast”. You need to learn how to ask the right questions. Quite often, paying an additional $20k a year for a bit more uptime is not what they meant by “always available” ;).
Modular monolith - architectural drivers
This article was intended to discuss the choice of the Modular Monolith approach, but I find it very helpful in showcasing how you can work with architectural drivers, and how they change over time.
Architecture Drivers comparison table
A handy table to compare the main architecture styles against the drivers.
—
OK, so we are now on the same page, we already know that there is no approach that will fit all the cases. You won’t be able to find the ideal solution for your project in blog posts, you will have to find one yourself, and in many cases — you will need to tweak it during the following years.
Before I jump into answering the question we started with, let’s consider another article:
Bottlenecks of scaleups — tech debt
Unfortunately, deciding on the right architecture is not enough. When building an MVP, you must cut some corners and create a bit of technical debt. How much technical debt is OK? This article tries to answer that question.
Different architectures are not equal. Creating a system based on Microservices is more expensive than creating a Monolith, but it scales better for larger teams. Sometimes, choosing one architecture might already be a bit of tech debt.
This is always a hard decision. But I believe that if you consider different options and decide on some simplification, having in mind the downsides of it, and the costs of switching that decision in the future, it is already 100 times better than just a random choice.
—
There is more material on the topic that I can cover, but let me stop here. I don’t want this newsletter to be too long, and I would like to try to answer the initial question ;)
How to work on an MVP of a product, and afterwards — scale it if required?
Let me start first with one end of the “quality” axis. If you’ve read the “bottlenecks of scaleups” article above, you already know, that you should avoid writing the initial code “too good”. It might sound counterintuitive, but writing overly sophisticated initial code can be detrimental in several ways. Before starting with complex architecture, please consider that many articles and resources on the topic are overcomplicating things. e.g. You really don’t need a super complicated queue setup to add an Event Driven Architecture to your system. Such overcomplications can spike the costs and kill the product before it blooms.
In short, my answer to the initial question would be: MVP has the word “minimal“ in its abbreviation for a reason. While creating an MVP try to postpone the big decisions for later. In the initial phase, your main focus should be the data - structure, but also interactions. Do a proper event-storming session and model what you can. If you have all that sorted out — it will be easy to polish things out in the future and complete the product. Don’t overengineer.
Yes, I know that in reality, it might be hard to model an MVP properly, as you are not quite sure how the final product will function and how to properly gather data. But that makes my point even more important, committing to an overcomplicated design at this stage will most likely result in more expensive changes later on. Narrow the scope to the smallest set of functionalities and find a domain expert to help you with product modelling. That approach will benefit your technical as well as business side.
An even simpler option (even if it seems stupid to admit that) is to go with the fastest way to deliver the MVP. Just skip all the event-storming sessions, complex planning and research, but within reasonable boundaries, not cutting corners on security etc. Check if the idea resonates with your target audience. And from there I would return to the best quality approach and write it from scratch.
The final answer is - as always - it depends ;) What is your answer?
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!