Maintenance deals (new contracts after delivery) to avoid wasting the money of the clients
CTO and Java Architect just do a periodical follow up with the finished projects to verify its stability with time.
Consider it yearly AKA proportional growth of the developed system like scalability and integration with other systems:
- more cubes to be added together whether within the same network (horizontal scaling to accept the traffic from more users) or
- with another networks (integration with another systems to do certain business activities AKA development work and its related activities till delivery).
Periodical analytics as I described earlier via scheduled-job-component is useful to see the future via a proper mixture of basics of math and statistics, so you can scale by time in the proper direction with less waste of resources.
Load on the system is defined by the number of users who hits the system to do their service. Note this number is fluctuate (peak time) by the day, and reach down to almost zero by night. Just take those notes into consideration. Besides users per business activity AKA rest-api-component.
Hint:
Admin dashboard shall be planned with the system under construction as well. Java Architect and CTO will be using it for yearly periodical check up to see if there is a need to do horizontal scaling or not based on the wisely collected analytics (number of users per service [functionality]. Just do business functions splitting wisely during the planning phase of the system under construction).
Design:
- APP (REST API Service):
1 replicawill do the job because only 2 users are using it yearly during the periodically check up (added in bothtesting environmentandproduction environment) - System actor type: user_admin
- Frontend Channel: WEB UI is enough
Upon a need for horizontal scaling, a maintenance contract shall be made to avoid draining the client with a lot of fucken bills. Just do upon intervention if there is a need from outside using the Admin dashboard as a guide for feasibility studies which you can use to take decisions later on this delivered stable black box.
Note that the contract monetary value is not connected with time of maintenance. Just notify and justify to the client upon need to stabilize the system over the long run as much as you can to get the most of it with time as a stable satisfiable service for end users.