Jaka architektura dla aplikacji? Kolejka, mikroserwisy?

Cześć, powoli zabieram się za projekt, chciałbym opisać pewien jeden usecase bez wchodzenia w szczegóły. Chciałbym to zrobić na mikroserwisach, tylko że jestem w tym temacie początkujący :)

1. Użytkownik uploaduje potencjalnie duży plik na serwer.
2. Serwer wyciąga z pliku pewne metadane (średnio intensywna operacja - raczej nie dłużej niż kilka sekund).
3. Użytkownik na podstawie metadanych, konfiguruje jakie biznesowe operacje może i chce wykonać na tym pliku.
4. Użytkownik wysyła na serwer żądanie rozpoczęcia obliczeń na pliku.
5. Serwer rozpoczyna obliczenia na pliku (bardzo intensywna operacja - nietrudno o dziesiątki minut).
6. Serwer wysyła powiadomienie, że obliczenia się skończyły i są gotowe do odbioru. ;)

Gotowe obliczenia, w formie dużego pliku, będą trzymane na serwerze przez jakiś czas. Każdy użytkownik powinien mieć wgląd do historii swoich obliczeń.

Operacja 6 jest długa. Jest tam spore pole do popisu jeśli chodzi o współbieżność, ale nie chciałbym sobie na razie dawać zbyt wygórowanych założeń. Dlatego jeśli byłoby kilku użytkowników, to myślę, że obsłużyłbym ich sekwencyjnie.

Jak powinienem do tego zamodelować architekturę?
Czy to brzmi jak usecase dla kolejki?
Jakie serwisy rzucają się wam na myśl na jakie powinienem to podzielić?

Brzmi jak executor tasków: https://airflow.apache.org/
https://spark.apache.org/docs/latest/web-ui.html

Corowe komponenty jakie widzę, to repozytorium plików, repozytorium tasków, executor i workery. Do tego jakiś powiadamiacz (notification service), ale może wystarczy pokazać status zadania na guju.

Pytanie czy nie możesz użyć czegoś gotowego jak np. Hive czy Spark? Wrzucasz pliki na jakieś S3 i odpalasz przetwarzanie. Jakiego typu to będą operacje?

Ewentualnie możesz to ogarnąć Quartzem, który się odpala co minutę i sprawdza czy są jakieś zadania do wykonania. Kolejkę potrzebujesz, ponieważ liczba instancji, na których możesz wykonywać przetwarzanie jest ograniczona, wiec żądania trzeba skolejkować i wtedy wolny worker pobiera kolejne zadanie. Zadanie zaczyna być tricky, jeśli zaczniesz zastanawiać się co zrobić, kiedy worker się wyłoży - mechanizmy ponawiania, współbieżności etc. To nie jest trywialne zadanie.

@Xorxorxor: Polecam pójście w monolit modułowy - nie masz na początku kwestii komunikacyjnych, a przejście z tego na mikroserwisy w przyszłości powinno być w miare proste

Mikroserwisy to raczej słaba opcja - chyba, że mówimy o warstwie mikroserwisów niewidocznych dla użytkownika, które wołają siebie wzajemnie przy kroku nr. 5.

Tak czy inaczej to opcji masz kilka.

Synchronizacja:

1. Przez polling (czyli klient odpytuje o status operacji raz na jakiś czas) - usługa z informacją o stanie, baza danych
2. Przez eventy (czyli po skończonej pracy klient dostaje info o skończonej operacji) - kolejka

Ogólnie opcja #2 jest bardziej preferowana, ale też opcja #1 może w niektórych sytuacjach być lepsza.

Gdzie wykonywana jest operacja:

1. Przez wiele niezależnych obiektów - mikroserwisy, Kafka Streams
2. Przez jeden komponent - Spring Batch, wspomniany Airflow
3. Coś pośredniego - Flink/Akka

IMO opcja #1 to overkill, który można używać i ma tę zaletę, że łatwo podmienić jeden kawałek na drugi. Problem się zaczyna gdy trzeba to utrzymywać.
Opcja #2 dla z góry ustalonych operacji jest najlepsza - ale tracisz na elastyczności przy opcji #1
Opcja #3 - wejście na taką swoistą platformę do odpalania jobów spowoduje, że monitorowanie (a więc i utrzymanie) będzie prostsze. Tak samo z developmentem kolejnych rzeczy. Ale koszt budowy takiego rozwiązania jest duży i trochę murujesz się przy danym rozwiązaniu.

Jeśli nie robisz nic wielkiego to proponowałbym jakiś MQ z części pierwszej + Spring Batch/Airflow dla części drugiej.

Pierwsza operacja to może być Lambda która analizuje ten plik i zapisuje go na S3.
Druga operacja to lambda + jakiś kod w sparku. Tu masz cos podobnego: https://www.startdataengineering.com/post/trigger-emr-spark-job-from-lambda/
Po przetworzeniu operacji jest trigerowana lambda, która zrobi co tam zechcesz

Chowasz to za jakims API Gatewayem i nikogo nie obchodzi ze masz lambdy pod spodem.

Można jeszcze dodać DLQ na te pliki, których nie udało sie przetworzyc.

Mało kodzenia i nie musisz sie za bardzo martwic o skalowanie i konfigurowanie infrastruktury :P

Pytanie
jak duży ruch ma to obsługiwać?
jakie sa rozmiary tych "potecjalnie duzych plikow"?
jaki masz budzet?
czy mozesz uzywac chmur publicznych?
jesli nie to czy macie w firmie zespol ktory zajmuje sie utrzymaniem infrastruktury np kolejek, event busow?