Mq изобретаем?)

Или изначально в очередь ставить задачи локальные. Создаёте несколько очередей

Вы что то имеете против велосепидистов?)

В первую отдаёте задачи с файлами, где парсите и отдаёте задачи на обработку в другую очередь

А другую очередь уже обрабатываете с вашими правилами. Если только вас не нужно эти данные из csv пачками вставлять в базу.

Но опять же, вставку тоже можно сделать через буферизацию

Или отдельную очередь

Как можно?! Поощряю, особенно если за свой счёт повышать собственную квалификацию))) Если и против, то наоборот, глобальных интеграторов не долюбливаю)

Ух, выдохнул))

постгрес про напряглись?)

А то все, велосипедист, велосипедист. Обидно даже как-то)

Не, еще глобальнее)

Например? А то я могу не знать)

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

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

Так такие фильтруются же на этапе обсуждения «Ок! Что нам нужно будет сделать и сколько это будет стоить?»

Если бы)))

По 2 причинам
1. Довольно часто выкатываем задачи, а не ждём релиза раз в неделю/месяц. Это придётся каждый раз пересобирать образ.
2. Файловая структура. Это моя личная боль. Куча папок раскиданных по разным местам в которые пишут/читают скрипты. И эти данные пользователи мог скачивать себе. Из-за этого нельзя просто так взять и запихнуть код в образ :(.

У меня есть другие сервисы - mongodb, sphinx, elasticsearch, mysql. Которые работают в докере и так же монтируется папки через volume чтобы сохранить данные. И к ним притензий нет.
Может быть потому что в самом сайте (код в расчёт не беру) очень много файлов?

1. Ну если сконфигурировать CI/CD то это не больно. Многие на практике релизят ежедневно, у нас например порядка 10 сборок ежедневно.
2. Из личного опыта скажу, что избавление от FS это не просто, но оно того стоит. В зависимости от платформы старайтесь использовать нативные средства хранения(google bucket, aws bucket), которые предоставляет платформа, если такие есть, конечно.

Важно понимать, что volume синхррнизирует данные между всеми репликами. Поэтому если изменений в FS много - то можете представить, как это расходится по сети. Что касается других сервисов, то они могут выполнять это в отдельных тредах. Например mysql сохраняет данные на диск параллельно и для этого используется специальная настройка, как часто сохранять данные на диск. В остальном mysql работает с оперативной памятью.

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

Спасибо за ответ, завтра буду с файлами экспериментировать...