If we use micro-service architecture to designed a e-commerce backend, then how backend services should interact to each other? using API or using websocket. If websocket, then how we should use phoenix websocket for backend services interactions? how scalable this solution would be?
How should we manage code of micro-service architecture e-commerce backend code in phoenix? By creating a separate project for each backend service?
These are not questions that are answerable in a general way. It depends on your teams composition, size, and experience with different technologies. It depends on the particular responsibilities of each microservice, and how entangled or independent each microservice is with respect to the other services. There is no one right answer, and even pointing you towards the direction of a right answer depends on a deep knowledge of your team and your use case that nobody on this forum has. Answering these questions for a particular company is what companies pay big money for, you aren’t going to get useful answers from people on the Internet.
While I do agree with @benwilson512 I’ll still give a more concrete take, based on a few assumptions and experience:
Erlang/Elixir are meant for long-running servers and not for quick one-off tasks (where Lambdas fall) or highly specialised smaller apps (the microservices territory).
All communication between microservices is bound to introduce network overhead and you also have to think of disconnections, timeouts, temporary outages and a lot of others.
Controversial opinion incoming: microservices are very rarely a good idea.
Make it a monolith, introduce your own linters (and
dialyzer!), put a few strict GIT pre-commit hooks and you shouldn’t have a problem with the monolithic nature of your project.
Furthermore, adding extra I/O latency is just going to make your system unbearably slow at one point. For a gain that’s questionable at best.