В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes. При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map.

Документация SQLite говорит, что -wal перестаёт расти, только если у читателей, которые видят кадры из -wal, бывают общие паузы, но не говорит, какой длины. Я замерил в контейнере на SQLite 3.46.1: на моём стенде хватало единиц миллисекунд — 2 мс при 50 коммитах/с, 5 мс при 1000/с, и быстрой записи понадобилась пауза шире. Без паузы три читателя по 50 мс раздувают -wal так же, как один на 20 секунд, а случайные запросы по 5 мс почти не мешали, пока база была свободна хотя бы 13% времени.

Когда в Laravel нужно обработать большую таблицу, обычно советуют «не делать all(), использовать chunk()». Совет верный, но неполный: у chunk() есть ловушка, из-за которой фоновая задача тихо обрабатывает только часть строк. Ниже замеры пяти способов обхода таблицы на 100 000 строк, разбор потери строк и правила выбора метода.