We conduct an architectural review of product features - Maxim Pedchenko - Yandex Go Product Engineering Meetup (Category Architecture)

Good. report Maxim Pedchenko from Yandex, in which he told why to conduct an architectural review and even showed a real example of what it looks like. Funny that the example was from the domain of referral programs, and simply put, how to make a feature with promo codes that a passenger can share with his friends. This feature is usually aimed at activating the mechanics of word of mouth, when you carry the customer acquisition cost not for advertising, but distribute it to the one who recommends the service and to the one who uses the recommendation and becomes a new customer. The marketing technology department that is part of my unit has services on this topic and they are called BAF. (Bring a Friend) And they bring in a lot of new customers. But if you go back to the report itself, then it describes the problems well + the algorithm of the archreview of product features is given.

• Emergence of project idea
• Hypothesis testing.
• The task of full development (with standard NFTs for reliability, security, and so on.) Creating an RFC/ADR with a description of the changes and then reviewing the standard flow of issues. In the report itself, the standard list was at the end of the speech and sounded something like this. What product problem does the project solve? What is the place of decision in the system What foulbacks are provided inside and outside What is the expected load? What components does the feature interact with? And the review examples dealt with real features, so the questions were in their context and they were like that.
• How many users (expected load)
• How to scale. (scalability) Can we make it better? (performance)
• What about the rejections and 500? xx (fault tolerance)
• Could there be a race? (What to do to ensure data consistency for parallel/asynchronous queries) How to make it more convenient for the user (Some optimal solutions from the point of view directly break UX in corner cases, which means you need to make it a little more complicated, but more convenient for the user.)
• Idempotence of challenges (including idempotence in time) If designed in this way, it is easier to ensure the reliability of the system, since conditional retroi will be safe. In the end, the author notes that the review should not last indefinitely and someday we should stop and say good enough, and then go to implement the designed solution. Otherwise, we can spin endlessly in the cycle of paralysis of analysis. The best is the enemy of the good.) For conditional experimental features, such a complex review can not be done, as it may be too expensive for the experiment. And the high cost on the one hand due to the waste of time engineers, and on the other hand due to slowing down the lead time changes. But if we're already doing something for a long time, then there's a lot of good for the archrevue on the long horizon. In order for the archreview to work, it is necessary to describe its goals and rules, as well as record the SLA for its conduct. (For example, the time in which it must be passed and the answer received)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems