Sometimes the most interesting challenges are where you least expect them. This story is about how a random interview turned into a detective story, a techno-thriller, and ultimately one of the most interesting projects in my career.
Prologue: An Interview Out of Curiosity
Two years of development. A team of programmers, expensive servers, a dedicated data center. All this was invested in creating a marketplace for one ambitious company. But at the time of my interview, there was still no working prototype. The management was losing trust and patience, and the technical director was on the verge of being fired.
I went there without much hope and wasn't even looking for a new job. Rather, it was professional curiosity to learn about the company's pains at that time. And then, during the conversation, the manager mentioned the name of that very tech director. The name was rare, and I recognized it immediately.
I had crossed paths with this person in the past. Back then, his approach to work—chaotic, undisciplined, and more like a "circus" than development—made me express everything I thought, after which our paths diverged. And here it was, déjà vu: the same person, the same approach, the same result—heaps of "beautiful" (in his understanding) but completely non-functional code.
My skepticism instantly evaporated. I was passionately eager to look under the hood of this failure and possibly help fix it. I agreed to join.
Diagnosis: Architectural Apocalypse
What I saw exceeded my most pessimistic expectations. The project's backend was a scattering of 20 (twenty!) microservices. Each one a separate Laravel application.
It was a classic "hype-driven" development mistake. Somewhere between 2018-2020, microservices were considered a silver bullet that solved all architectural problems. They were implemented everywhere, without considering team size, product complexity, and operational costs. I had stepped on this rake before and knew that microservices are not about system scale but about team scale.
And what was the team? After two years of fruitless efforts, only one exhausted developer remained from the original backend team. Imagine: two people and twenty microservices. This is not architecture. This is masochism.
The complexity of deployment, debugging, ensuring data consistency, and monitoring was off the charts. Microservices didn't break up the monolith—they fragmented the context and killed productivity.
Treatment: Harsh but Necessary Surgery
It was difficult for me to convince management of the need for a total architectural overhaul. Not everyone had the time and desire to delve into technical details. So I acted on intuition, with the sole aim of saving the project.
The solution was radical: kill all microservices and assemble a modular monolith.
In a few days, I rewrote the backend, combining everything into one cohesive but well-structured Laravel application. The modular monolith gave us:
A unified codebase for all developers.
Simplicity of deployment—now it was necessary to launch one project, not twenty.
Development speed—the need to configure complex interactions between services disappeared.
Context preservation—a developer could work with a function from start to finish without jumping between repositories.
Simultaneously, the issue of integration with 1C, which was a sore subject for the previous tech director, needed to be resolved. My principle is simple: to get the job done, I'm ready to work with anyone. We found common ground with the 1C guys (special thanks to Dmitry), and in the shortest time, set up stable synchronization.
The next step was infrastructure. The complex and heavy-to-maintain Kubernetes was excessive for our new monolith. I migrated everything to Docker Swarm—a simple and resilient tool that was more than sufficient for the Laravel + MySQL + Nuxt.js bundle on the front end.
Result: Presentation Against All Odds
We had no time. An internal presentation for the company's owners was looming, which was supposed to decide the project's fate after two years of development and significant financial investments.
Without ChatGPT, without a large team, almost alone, we did the impossible:
Rewrote and unified the backend.
Tweaked the frontend.
Built CI/CD for the new monolith.
Rolled out a working prototype.
The managers were able to show the owners not just expense reports, but a live, breathing product. I remember the chief manager telling me, "You saved us." It was sincere and meant a lot.
Later, the project became the company's locomotive. Based on it, we launched several more directions. For me, it was another lesson confirming a simple truth: there is no perfect architecture for all occasions. There is an architecture adequate to your team and product at this stage of its life.
Sometimes the most elegant and effective solution is not to add another complex technology but to have the courage to remove the excess. Even if it's 20 trendy microservices.
P.S. Sometimes I still receive notifications from the monitoring system. If I see that the guys aren't responding, I write to familiar managers to suggest where to look for the cause. The connection of times hasn't been broken.
Leave a comment
Comment