During the second semester of my first year at UNIMI, we had a very useful course called Advanced Data Management.
For me, this course was important because these skills are valuable not only in BigTech companies, but also when building larger product-based systems. As the number of users in a system grows, the solution is not just to buy a bigger server. It is more important to understand how to keep the system stable, maintain data consistency, and use resources efficiently.
Through this course, I learned how systems can be designed to adapt flexibly when traffic increases or decreases, remain reliable under load, and make the most efficient use of limited resources.
In particular:
- this course helped me understand that system design is never perfect. Every system eventually faces new problems, new limitations, and new architectural decisions. That is why there is never one universal solution, and in system design discussions, the right answer often starts with “it depends.”
- We explored what really happens behind concepts such as ACID and BASE, when different distributed system approaches should be used, including scale in, scale out, and shared memory, and how Big Tech products continue to serve billions of users reliably at scale.
- I also try to apply these ideas in our own products. For example, if users fully rely on a system, we need to think about data recovery in case something is deleted, regular database backups, automatic error notifications, daily statistics, useful dashboards, and simplifying the parts of the system that users interact with the most.
This kind of End-to-End monitoring makes the product more reliable, understandable, and convenient for businesses.
(Simply put: if people are already using your product, the system should continue serving them even when you are offline for 4–5 days. It should automatically handle important processes, send notifications, store data safely, show statistics, and help the business keep working without requiring constant manual control from you.)
Ideally, the system should be able to handle most daily operational tasks on its own without requiring engineer intervention: monitoring service health, creating backups, sending reports and notifications, and executing standard recovery procedures automatically.
The engineer should only be involved in highly specific, unusual, or critical situations where automation is no longer sufficient and human decision-making is required.
At first glance, these examples may look like small and simple features, but good automation is often built from exactly these kinds of details.
For example:
- - sending users daily reports and statistics automatically;
- - reminding customers a few days before limits are reached or subscriptions expire;
- - automatically guiding new users through the first steps of using the system;
- - notifying account owners about new login activities;
- - generating alerts when requests come from anonymous users or unusual activity is detected.
I believe that by introducing many small improvements like these, step by step, it is possible to move toward a highly automated system that requires minimal manual intervention and helps businesses operate more efficiently.
P.S. A special thanks to Azimjon Pulatov and the 42.uz team for the System Design course. It helped me better understand how modern systems are designed, scaled, monitored, and maintained in production environments.