Distributed systems: If you can drive you can architect a system (6 things you should not forget when architecting a solution)

Even the best engineers sometimes struggle with architecting their services, especially when talking about complex data flows and components dependencies. Engineers more than once miss important concerns in design, and from my experience, it’s usually due to lack of awareness and/or knowledge and not lack of motivation.

In this talk, I will try to simplify a complex subject, by demonstrating how natural solution architecture can be if you use a different perspective, implementing similar logic from a driver’s daily life through architecture challenges. We will start from one example of such trade-offs and design principles as they could be demonstrated even in a simple question as “which car would you buy?”. What will your answer be if you have 1000$? And if you have a budget of 10M$, Would you buy the same car? Will it affect your decision If you driving 10 mins a day? 10 hours a day?

Later on, I’ll demonstrate how architecture is affected by constraints and why everything is a tradeoff. I’ll show visually step by step how complexity creates constraints and limits the things we can build. Constraints eventually lead us to what we’ll choose as our building blocks, but we must be aware that each restriction will have ripples in your design. In each step, we will cover the principles, trade-offs and things you should NOT do when architecting a solution.

My most important goal is for people to understand that architecture is all about tradeoffs, “expensive” is not always the best and “perfect” does not always serve us.



Ayelet Sachto

Ayelet is a Strategic Cloud Engineer @Google leading PSO-SRE efforts in EMEA, currently Site Reliability Engineer @GKE London team. Throughout her 17 years career, Ayelet was successfully leading ...