На чем реализовывали поиск

Что проверяют

Вопрос про ваш опыт, а не про теорию: хотят услышать, какой именно поиск вы делали, из чего выбирали и во что упёрлись. По ответу сразу видно, работали ли вы с реальными объёмами или прикручивали LIKE к сотне строк.

Как отвечать

Начните с условий, иначе любой вариант будет наугад: что ищем, сколько данных, нужна ли морфология и устойчивость к опечаткам, какая задержка допустима, как часто данные меняются. Затем назовите решение и его цену:

• поиск по подстроке в PostgreSQL: ILIKE работает, но шаблон с ведущим процентом не берёт обычный индекс, спасает pg_trgm с GIN;
• полнотекстовый поиск в самой базе: tsvector с GIN-индексом и ранжирование через ts_rank. Хватает надолго и не добавляет отдельного хранилища;
• внешний движок вроде Elasticsearch, OpenSearch или Meilisearch, когда нужны фасеты, подсказки, опечатки и сложное ранжирование. Плата за это: индекс надо наполнять, следить за расхождением с базой и переживать его недоступность;
• bleve, если индекс должен жить внутри процесса на Go без внешней зависимости.

Со стороны Go расскажите про обвязку: context с таймаутом на каждый запрос, пагинация по курсору вместо OFFSET, отдельный воркер на переиндексацию, кэш популярных запросов, ограничение длины и частоты запросов с клиента.

Где спотыкаются

Называют Elasticsearch рефлекторно, на любых объёмах. Отдельный кластер это новая точка отказа и новая эксплуатация, и на паре миллионов строк база справляется сама.

Молчат про консистентность. Индекс наполняется асинхронно, значит бывает окно, когда товар уже есть, а в выдаче его нет. Нужен ответ, как догоняете: очередь событий, периодическая полная переиндексация, версионирование документов.

Забывают про язык. Русская морфология без словаря превращает поиск в поиск по точной форме слова, а исправление опечаток и синонимы решаются отдельно от самого индекса.