I am currently developing a service and its current architecture is monolithic. So, when a client clicks, the front end connects with the backend service. On the backend, currently it is designed in such a way that it calls a master method which then manages other methods sequentially waiting for its response. The API calling the master would start a thread and give HTTP response as 202 immediately. Currently the backend is in single pod. Logic is something like
master(request):
m1 = callMethod1(request)
if m1.message == 'OK':
m2 = callMethod2(request)
if m2.message == 'OK':
m3 = callMethod3(request)
#around 10 methods like this
else:
#fail
callMethod1(request):
#do something with request
#update database
#return the status
callMethod2(request):
#do something with request
#update database if pass(OK) or fail(ERROR)
#return the status
Concurrent users for this application would be not more than 150.
Tech stack:
- Front end - React
- Backend - Django
My questions:
- Should I convert each methods to an API and put it in individual pods?
- If so, what pattern do I use, orchestration or choreography?
- If choreography, what is an cost efficient way to do the publisher - subscriber functionality? Redis or Service Bus?
- Or should I just stick to the present architecture?