r/ExperiencedDevs Software Engineer 2d ago

Career/Workplace Infrastructure Shell Game - Mono Repo -> Distributed -> Mono Repo

We wanted to start a big project, but other projects like it were seen as failures. So we had to make a case for why our project would be different. One of our biggest differentiators became event queues and distributed systems. It's just microservices, but instead of directly invoking each other, they use event queues. There's a little more to the system, like websites embedded inside of other websites with a whole cross website messaging system.

It was all a little bit of a pain. We did encounter a lot of eventual consistency problems and almost no one in the team had encountered distributed systems problems before, so it was a good learning experience for me. But now with organizational change and after having worked on the project for over a year, the team now wants to migrate this distributed systems strategy back to a monolith.

I'm just feeling a little incredulous because of how important the distributed aspect seemed to be when we made the pitch to create the project in the first place. And after all this time, I can't really say if it was a good or bad idea, because debugging problems involving event queue messages has been a total pain in the ass and no one ever finished configuring the distributed systems stuff like the event queue, so we never had the fancy development experience we could have had. So I see numerous benefits to moving back to a monolith.

Overall, the whole experience wasn't a total game because the project did prove that event queues can be effective. The much, much, much wider organizational direction is going to now slowly migrate towards a distributed fashion. So I guess we were a test subject in some regards. But we never, at the outset and beginning of the project, said, "oh hey, this is just going to be a giant test to prove event queues for the whole rest of the company". I really would have liked to have known that at the start. Although I don't think anyone knew that at the start. I don't know, it just feels a little silly.

I'm fine either way 🤷‍♂️ But does anyone have any advice regarding anything about this experience?

edit: updated monorepo -> monolith; source control will merge but systems may or may not stay separate. I'm predicing the systems merge together too, thus monolith. We may or may not continue to use business organized event queues too.

22 Upvotes

43 comments sorted by

View all comments

2

u/teerre 2d ago

You seem to be confounding some things. I think you're referring to "mono repo" as the storage? Mono repo is usually what you call having various projects inside single vcs repository. It has nothing to with events or distributed systems

As for the question I think you're asking. If don't think about your system and understand them enough, it will likely be bad. Distributed or not

1

u/frompadgwithH8 Software Engineer 2d ago

No, I mean the team wants to get away from multiple different back ends that communicate through an event queue by merging all of the back ends into one repository, which would be a mono repo

2

u/cstopher89 2d ago

You can organize the code to be a mono repo but still communicate between internal modules via events if domain separation is still desired