I would say that the biggest bottleneck in the project was the implementation of the messages. If service A sends a message to service B and is waiting a response, the response won't be sync, I mean the response from service B won't the response of the method call to send the message as you can expect with REST so in this case what will happen is that you design will need to take account messages that will arrive to services in an async way making the programming model a little bit more complex than using REST. There is a nice advantage and it's that if you have multiple instances of service X listening to the same queue you can use the "competing consumers" model to get load balancing out of the box from the queue service (this works well on ActiveMQ) so you can avoid adding an extra service just to do the load balancing of the microservices. Hopefully this helps you

I use switch statements when I know that the switch will contains 2/3 maybe 4 options and that number will not grow in the future. But there are situations in that you know that the amount of cases in the switch will grow over the time so in that case I really like one pattern I have implemented a long time ago, you can see an example of that on my comment on this post: https://hashnode.com/post/best-practices-in-handling-mqtt-messages-with-paho-java-library-cimqbf88700p0wz53wwjom9zn

There are many alternatives to answer this question and always depends on the use cases of your application. In my experience REST apis are the easy way to go, but queues or topics are easy to implement as well. In my last project we ended up with a hybrid approach where the communication with some services was using rest and in other places where the order of the messages was important we used queues. So the bottom line is: you need to clearly understand the requirements of the application, you really need to know the how the data fill flow into your app and base on that create the the constraints that will help you to decide what's the best solution. That being said, I have one recommendation, please start from the easy and then iterate over the solution until you get the final architecture.

We are using git to store our configuration for each environment. For instance, we have branch for each environment i.e dev, qa, etc and then we have a tag for each production release. Then we use https://cloud.spring.io/spring-cloud-config/ in our apps to read the configuration from git. So far this is the best approach I have used in all the projects I have worked on.

I would say that 20% is the time that I spent coding the solution, the rest of the time in my case is used in the following tasks: thinking the solution to the problem calls and meetings emails updating and writing tickets in tracking tool reading/learning all these things are part of my working day.

I'm a backend guy, I been working on backend for the last 10 years or more. In the last two projects, I had to take the lead on the front end development not only by deciding the tech stack but also coding the complex parts and also helping the front end guys to solve some problems, even when this is requiring from me extra effort I'm really happy because I'm learning a lot about web front end development which it's becoming more robust and nice to work these days with libraries like react and frameworks like angular. So as summary, yes, I think that it's an opportunity that makes you to grow as developer and helps you to help more to estimate those tasks that are outside of your "confort zone".

They have not the same functionalities, react has a lot less functionalities. React it's a library focused on the view, so you will need to use other libraries to create the whole app, instead angular is a framework, you can create your entire app with it and no need for other libraries. My suggestion: go and spend a few days learning about each one and try to implement the same app with both, for instance try to create a todo app with react and then the same with angular, but try to do it by consuming rest services etc. After that you will have an idea about each one.

We have a similar approach to this one, but instead of hours we use Story Points

I found this site some time ago: http://musicforprogramming.net The music list it's pretty nice and help me to keep my focus while working, it's interesting what they say in the about section.

First of all, why terrible, messy etc code it's faster to write than good code? Probably you can write good code in the same time, this good code maybe will be not the best in terms of performance but that's all. My recommendation is: try to do your best effort to write good code even when you are in a hurry.