Context
Planning production means pulling together demand, product recipes, stock, and line capacity, and each of those is owned by a different part of the business. The system splits them into separate services behind one gateway.
My role
I maintained the system and built new features across its services, mostly the UI, KPIs, the planner, and products, with smaller work in supply, demand, make-to-order, and warehousing.
Architecture
- Every request enters through an NGINX gateway, which checks it against the auth service before forwarding it to
/api/<service>/. - Each business domain is its own service. Some are Laravel on MySQL, others Express on MongoDB.
- Some features span several services. For example, before a week’s plan is confirmed, the material check pulls the schedule from the planner, bills of materials from products, and stock from warehousing.
Design decisions & trade-offs (as I found them, and worked within)
- Gateway plus a dedicated auth service. Domain services don’t each implement login and token checks. Trade-off: the gateway and auth service are on the path of every request.
- Service per domain, two runtimes. Each domain can change on its own schedule. Trade-off: features that cross domains, like the material check, mean touching several services, two languages, and two databases.
Stack
Laravel · Node.js · Express · Vue 3 · Quasar · MySQL · MongoDB · NGINX · Docker