Is this too much for a modular monolith system?
A little background before I ask my questions. I've designed a system as an architect based on the requirements given to me by the client. The client has a team or two to three developers which are good in react, typescript and Laravel (Php). They want a system that offers different modules to the user (Domain is Customer Management System). They want a system in which modules can be subscribed to, independent of each other. The system should not be very difficult to implement It should cater the needs of approximately 10-25 users initially, but they have plans to extend it to 1000+ users later. The client was very much inspired from microservices so I had to convince him to go for a monolith which then can later be migrated to a microservices. besides to me microservices for a 3-dev team is a joke. my system design is like the backend is in Laravel/Php. Each module is kind of independent in a way that in a module (which are all hosted in one codebase) have their independent databases (think of separate schema in postgres) which do no utilize or talk directly to each other. if they want to they would have to send out messages to communicate with each other. so I have Module A (Postgres) Module B (Postgres) Query Module (See below) RabbitMQ for messaging Redis for Caching Since there are various queries that require distributed joins (because the databases are separate and modules cannot talk directly) so the Query module serves queries, which are denormalized datasets. whenever there is a change in database a message is sent out, and query module reads it gathers the data from different services (calling their Rest end points) and then updates the dataset. so all the screens in the UI show the data from query module but the changes are made to actual modules. For hosting, this is my design requires 5 machines. All API can be hosted on 1 machine, Container (nginx + PHP-fpm) Postgres can be hosted on one machine Redis and RabbitMQ can be hosted on single machine. Background jobs can be hosted on one machine. Container (Php-fpm + SupervisorD) Frontend (React App) can be hosted on one machine. Container (Nginx) there is now the requirement of background tasks. it seems Php only runs one job at a time even if there are multiple listeners hosted in a job. they listen to their Queues sequentially. that's' how Laravel jobs work. so I have these questions. In your opinion, is the design correct as a modular monolith or is it too much considering the team of only 3 developers? are there any changes you think are needed to simplify it further? what are those changes? is Php an okay choice for background jobs or should NodeJS be used for background processing? for the query module, is MongoDB a fine choice or should I stick to Postgres or use ES? full text search is needed. Do you think the deployment design is okay or can it be reduced? if this is too much a monolith. what is your review based on the requirements and proposed design? is it easy for a 3-dev team?
A little background before I ask my questions. I've designed a system as an architect based on the requirements given to me by the client. The client has a team or two to three developers which are good in react, typescript and Laravel (Php). They want a system that
- offers different modules to the user (Domain is Customer Management System).
- They want a system in which modules can be subscribed to, independent of each other.
- The system should not be very difficult to implement
- It should cater the needs of approximately 10-25 users initially, but they have plans to extend it to 1000+ users later.
The client was very much inspired from microservices so I had to convince him to go for a monolith which then can later be migrated to a microservices. besides to me microservices for a 3-dev team is a joke.
my system design is like the backend is in Laravel/Php. Each module is kind of independent in a way that in a module (which are all hosted in one codebase) have their independent databases (think of separate schema in postgres) which do no utilize or talk directly to each other. if they want to they would have to send out messages to communicate with each other. so I have
- Module A (Postgres)
- Module B (Postgres)
- Query Module (See below)
- RabbitMQ for messaging
- Redis for Caching
Since there are various queries that require distributed joins (because the databases are separate and modules cannot talk directly) so the Query module serves queries, which are denormalized datasets. whenever there is a change in database a message is sent out, and query module reads it gathers the data from different services (calling their Rest end points) and then updates the dataset. so all the screens in the UI show the data from query module but the changes are made to actual modules.
For hosting, this is my design requires 5 machines.
- All API can be hosted on 1 machine, Container (nginx + PHP-fpm)
- Postgres can be hosted on one machine
- Redis and RabbitMQ can be hosted on single machine.
- Background jobs can be hosted on one machine. Container (Php-fpm + SupervisorD)
- Frontend (React App) can be hosted on one machine. Container (Nginx)
there is now the requirement of background tasks. it seems Php only runs one job at a time even if there are multiple listeners hosted in a job. they listen to their Queues sequentially. that's' how Laravel jobs work. so I have these questions.
In your opinion, is the design correct as a modular monolith or is it too much considering the team of only 3 developers?
are there any changes you think are needed to simplify it further? what are those changes?
is Php an okay choice for background jobs or should NodeJS be used for background processing?
for the query module, is MongoDB a fine choice or should I stick to Postgres or use ES? full text search is needed.
Do you think the deployment design is okay or can it be reduced?
if this is too much a monolith. what is your review based on the requirements and proposed design? is it easy for a 3-dev team?
