Вайбкодинг против сотни шардов: как я за пару дней собрал Terox
A backend developer and former DBA built Terox in just a couple of days. The service runs on a hundred PostgreSQL shards, so even finding a record by its ID can mean going through dozens of connections. Entities are distributed by consistent hashing, and rare operations on heavily loaded tables require separate monitoring of lock_timeout, statement_timeout and the connection pool.
Когда сервис живёт на сотне PostgreSQL-шардов, даже вопрос «где лежит запись с таким ID?» легко превращается в обход десятков подключений. Сущности распределены консистентным хешированием, а редкие операции на нагруженных таблицах требуют отдельно следить за lock_timeout , statement_timeout и пулом соединений. Я бэкенд-разработчик высоконагруженных сервисов, в прошлом DBA. Штатные миграции у нас раскатываются автоматически. Но когда изменение требует отдельного контроля на нагруженной таблице, не хочется полагаться только на то, что разработчик проверил скрипт и ничего не забыл. Так за пару дней совместной работы с ИИ появился Terox — CLI, который ищет данные по набору шардов, переключается на найденный и раскатывает сложный SQL через dry-run, canary и батчи. Рассказываю, как рабочая боль превратилась в open-source инструмент и почему при работе с production-базами вайбкодинг быстро превращается в обычную инженерную работу. Приручить сотню шардов