as a short background: I'm the only backend engineer at my company and mostly building out the foundation for the backend architecture and infrastructure to support future growth. My boss has great technical vision but is a subpar programmer - he works he's not too great at programming but he still does quite a bit of coding in the backend/frontend along his usual work to try to speed up development. The business is bootstrapped and there currently is no money for an additional developer.
However, the underlying architecture that he envisions and partially built out himself is very brittle and I think extremely overdone. He wants to build microservices because of scaling and throws out any data consistency and timing concerns. Almost every type of business record will get its own CRUD microservice and its own database and fetching nested records will require calling other services.
I don't think this software is ever going to go above 1k concurrent users because it is very niche and will mostly be used internally by consultants and only some external access. I want to convince him to turn this into a monolith, strip out most of the abstractions (there is a lot of abstraction on top of abstraction) because I believe we'll get a working piece of software out of the door much quicker than trying to finish connecting all the loose ends that are floating around.
My question is: How can I approach this? This thing is his baby and he thinks he'll have the need for microservices like scaling in the future. He says he doesn't want to change too many things because it's so much work re-writing some stuff and we're almost there. I think we're not almost there and building a simpler architecture out of what we have will take much less than finishing what is there.
I want to try to convince him without but I think just sending notes and bullet points might make him get defensive and less likely to listen. What is a style of writing/talking I can use to make sure he'll understand me and that it will reach him without me invalidating the amount of work he did?
It helps to be very honest about the current state of the application and take specific note of why things were done that way; ie "Chesterton's Fence". Even if the reason is "because I felt like it", the decisions should be retrospectively documented.
Next you want to present an informal vision of the way it COULD be. In your case, you'd want to paint a picture of daily life in a monolith, and contrast that to your current system. Do not push strongly for your solution at this point; keep it conversational, "what ifs".
Now comes the hard part, getting from here to there. Burning it down and starting from scratch is rarely an option. You need to propose a series of refactors (linear, since you're 1 developer) that will eventually get you to the final place. But the trick is, the changes can't break the existing app and changes need to be incremental and self-contained such that you can stop and work on features, bugs, etc. Focus on the high-priority stuff first, realizing that you may never fully get there.
Finally, there's a real chance that the boss will say "No thanks, this doesn't add value". Then it's your job to start documenting technical debt interest payments. In your case, this should be pretty easy - any time you have to deal with a data inconsistency or a race condition, it's 100% interest since there are known solutions - your boss chooses not to use them but he should at least be made aware of the cost and drag this puts on velocity.
Learn instead.
Maybe you are wrong technically.
Probably you are wrong socially.
Because if someone wants your opinions, they will ask.
And because your boss is your boss.
And because usually everyone working together in a common direction is more likely to succeed than debating past decisions and throwing away work.
But mostly because you being paid because what needs to be done is work.
Good luck.