Свежее видео как обещал
https://youtu.be/iEaIjrYz14w?si=Jk7IRPIoIuYTbbrR

Давно вже нічого не розповідав по теху, тому вирішив сьогодні трохи поговорити про розгортання проектів, та побудову норм інфри так щоб всі були раді)

https://youtu.be/qGLiwg4_hlQ

Подключаемся на стрим
https://youtube.com/live/ERrRBBYIQe8?feature=share

🔥 Software Architect Decision: Typical Fail in Designing Search

Many services - like search engines, marketplaces, online stores, and social platforms - heavily rely on search functionality. For some, it’s absolutely core. Yet I still see developers making the same mistake over and over.

The image you see is from a #YELP Proximity Service #SystemDesign
Interview. And, again, we see the same flaw.

So what’s wrong with it?

You need to understand: search is usually a heavily loaded service and, as a core component, must be highly available with low latency.

In this design - and in many similar solutions I see on the market - the architect has split listing data: metadata goes to #ElasticSearch, while listing data is kept in a #RelationalDB.
The metadata (geo-coordinates, listing type, ID, maybe a title, etc.) is in ES, while the DB stores image paths, descriptions, titles, and so on.

So, for every user request, you first search ES for metadata, then request the rest from the DB. This approach increases system load, adds latency, introduces retry problems, creates balancing headaches (since the DB must always be more available than ES to avoid being crushed by ES-driven queries), and adds failure paths - basically increasing inconsistency and overall system complexity.

You might say cache will help. Sure, it will - to a point. But it also brings its own problems: stale cache, cascade failures, and even more complexity.

So what’s the right approach?

Instead of splitting across ES and the DB for search, make ES the only source for the search path. Add the necessary extra data to ES (usually, this increases data volume by less than 20%). Leave the DB as the source of truth, and sync ES dynamically and reliably with it.

This approach eliminates many issues and greatly simplifies support.

DISCLAIMER: As always, there’s no silver bullet. This works in many cases, but not all. Always weigh the pros and cons before choosing your architecture.