[royalghost]

Looking at the problem statement, this should be built in a Reactive style of programming and more event based. What if we need to scale this to infinite numbers for millions of clients ?

Event based programming in technology like stack is more appropriate for this kind of problem domain...

[kartan]

> What if we need to scale this to infinite numbers for millions of clients?

I worked for a company where an internal tool for, at the moment, a dozen users was designed to be more scalable than the actual product. The product was used, without major problems, by hundreds of millions of users. So we had a team of 14 people to build something that previously was done by one guy in an already maintainable way.

The server was also divided into several components to mimic a micro-service architecture. Even that no one else was using any of the services and it made deployment cumbersome.

To cut a long story short, the company has a-lot-of-money to throw at problems. So waste is not a big deal. I moved on, as it was boring to work that way.

Many backend developers feel proud of their complex architecture. Simplicity is seen as "not being professional".

For the client side of that app, there was just one guy. He was also acting as scrum master because he had spare time.

[acobster]

I've faced a similar situation, where a team I came to work on mid-project had designed a microservice architecture where a WordPress front-end talked to some "middleware" (a total misnomer since it was actually a REST API) which in turn talked to a bunch of other intermediate services which in turn talked to the CRM, an accounting system, and other third-party systems. Most of the "middleware endpoints" simply forwarded the calls to other services. Any feature that required a new endpoint usually meant deploying changes to three different systems.