Simple is Scalable with Product Architect Mojtaba Saroonghi

Episode transcript:

Jose
Hello and welcome to this episode of the Smooth Scaling Podcast, where we interview industry experts to really understand how to design, build, and run scalable and resilient systems with the ultimate goal of providing a great user experience. I'm your host, José Quaresma, and today I'm joined by Moji, a distinguished product architect at Queue-it, to talk about why simple is scalable. We really talk about broader scalability—how we see that, how Moji sees that—and we deep dive specifically on simplicity and why that is such an important part of scalability, not only from an architectural perspective, but also in software development itself, and around processes and how to run an organization. Moji, welcome to the podcast.

Moji
Thank you, José. Nice to be here.

Jose
It's super good to have you. So you started at Queue-it around 10 years ago, is that right? Can you tell us a little about your background—how you got to Queue-it and maybe a bit about the journey?

Moji
I've been in this industry—programming, software technology—for probably 18 years or so now. I was doing some tools development back in Iran. Then I was in Finland doing some programming there and doing my master's there. And then I started working at Queue-it 10 years ago. At that point, when I joined, we were pretty few—actually 10, 15 people. And now we are 200. And I'm enjoying this ride with great colleagues like you.

Jose
Thank you. And maybe getting started—because we’re talking about scalability, and that's a big theme for our podcast—can you tell us, how do you see scalability? What are the key factors of a scalable system?

Moji
When you have a simple system, you can scale it pretty fast and reliably. It kind of makes sense. Even if you want to look at the whole textbook—the CAP theorem. In the CAP theorem, you have three factors: availability, consistency, and network partition. You can’t have all of them together. You know, if you want to have everything, it’s not simple. So you need to choose between them. Usually, when you want a scalable system, people go for availability and network partitioning. So they let consistency go and the system becomes eventually consistent.

That’s one of them. Then we can go further down on the simplicity point. Another factor would be: when you're creating the system, make it less dependent on other systems. Again, we're talking about simplicity—a simple system that doesn't need other systems. So it doesn’t need the network, it doesn’t need I/O. It just, as a component, is self-sufficient.

We can continue on this topic under simplicity—don’t have too many background calls. Just make it simple: get the request, do your logic, respond back. Not much of these background tasks.

And then there are other factors. I don’t know if you want to consider them simple or not, but it could be things like: don’t block the request. When you're supporting high throughput—and at Queue-it, we do millions per minute—you need to get the request, don’t block the users, respond as fast as possible.

And the final thing, which may not be part of the system but part of your process: always do load testing and always have some kind of measure for how your system reacts under load.

Jose
Would you say that simplicity is inherently better? I mean, are there any scenarios where simplicity maybe isn’t the way to go?

Moji
Yeah, I would say that yes, it is the best solution. I’m usually not 100% this side or that side, but related to simplicity, I would say yes.

Let’s talk about a specific scenario: you get the request, you want to have some state. But let’s make it simple—don’t have that state on the server side, just make your server stateless. That’s again a simple system. If your system doesn’t depend on anything, doesn’t have any state, and just does logic fast without blocking—that’s the simplest system. And if you have that, you're able to scale really well.

Jose
But when you mention having a stateless system at that level, you still need to keep state somewhere. Are you just kind of moving the bottleneck or the concerns further down the stack? How do you balance that?

Moji
Exactly, that’s a good question. This is again the trade-off. Do I need state? Yes. We’re not living in a perfect world. But what if we put some stuff on the client side? What if we hash the data?

Sure, when you're putting information on the client side, then you need to think about security, encryption, and all those concerns—can you trust that? But yeah, there are ways to do that.

And then, okay, now I need something on the server side—but does it need to be a database? And if it’s a database, what kind of database? Does it need to be a consistent database, or can you use a NoSQL database?

At Queue-it specifically, we try to use the most scalable NoSQL database. One of the best is DynamoDB from AWS. It’s pretty good at scaling fast and very reliable, so I would use that as well.

You're right—we can’t always stick to that motto of wanting something super simple, with no dependencies. But you need to keep that in mind and wisely choose your components.

Jose
Maybe going back to the broader scalability part, but still on simplicity—do you have any specific guidance or tips for teams trying to bring simplicity into their system design?

Moji
Yeah. If I think about it, I go back to how I started—dependency. Dependency is one of the key factors. Does your component really need to communicate with, I don’t know, 10 different other services? Can you make it just four?

In software architecture, we have this concept of coupling and cohesion. Your system needs to have low coupling to others, but also high cohesion—it should be self-sufficient. Maybe the service you're designing can actually be divided into two. One part might not need to communicate with many other systems, and the other part might. So we keep that separation through modularization and decoupling.

Now, this might sound a bit controversial, but I’m also on the side that simplicity doesn’t mean the system or service is small. I don’t agree with the idea that your service should be just one line of code. That’s not realistic. But dependency can still be minimized. Even in some scenarios, if you put some logic in one system, you don’t need to call another system—which is a win.

Let me give an example. Take the state example we discussed earlier. I could call another service to read from a cache or a database, but I could also use an in-memory cache in my service. In that case, I’m coupling my system with a memory cache—but from a scalability point of view, I’m keeping my service less dependent on others. So when I scale, I’m just scaling this one service, not several at once. That’s a benefit.

Jose
Yeah. Yeah. Are we touching a bit on the idea that there’s a scale—from having one monolith for your whole system, to everything being a one-line microservice? So it feels like you're talking about that trade-off. Of course, if you have everything in a monolith, there are no external dependencies—everything is in there. But if you go to the other extreme, each service becomes simpler, but you’re adding a lot of dependencies. Is that what you're getting at?

Moji
That’s 100%. You’re spot on. It’s a big ongoing debate. I think it’s kind of a dialectic process. In the past, everyone wanted everything in one monolithic system. Then another group came along saying everything should be microservices—I even read something suggesting every line should be a service.

But realistically, I think the best is somewhere in the middle. And now, I see people gradually realizing we may have gone too far in the microservices direction. Finding that sweet spot is probably best, because of the failure points.

That’s another aspect—simplicity, fewer dependencies, easier to scale. But if I'm depending on 10 different services, I now have 10 points of failure. And I need to scale all 10 services at the same time.

Jose
And with a lot of services, you're also adding complexity in how you manage updates—how you coordinate changes between services, right? That’s another layer of complexity.

Moji
You’re absolutely right. Simplicity isn’t just about scaling—it’s also about process: deployment, development time, all of that. And monitoring, which I haven’t even touched on yet.

A scalable system needs good monitoring. But now, if you have 10 different services, you need to monitor all 10 at the same time. And, as you mentioned, orchestrating between services is not an easy task.

So again, finding that sweet spot is the key. Don’t go for a giant service, but also don’t go too small and lose cohesion. Back to that idea of coupling and cohesion: your service needs to be small—but small enough. Not too small, or you lose cohesion.

Jose
I like that. So maybe going back up a bit from simplicity toward scalability as a whole. We work across a lot of industries—probably almost all of them, or close to that. Are there some patterns or characteristics of scalable systems that you see as common across industries?

Moji
Yes. At least for us, we have one system that, as you mentioned, works across different industries. Our system integrates with other people’s systems—they might have an online shop, or something that has to fight off bots and handle high-frequency traffic.

All those systems need to be scalable, like ours, because we get huge traffic. And if it’s Black Friday, for example, an online shop will get huge traffic—they need to scale as well.

So, for sure, there are a lot of similarities. And again, going back to simplicity—less dependency, making services self-sufficient, not depending on too many others. I’d say those are shared concerns, regardless of the industry.

Jose
Continuing in the theme of Queue-it and how we do things—is there a specific example, maybe from the past year or even 10 years ago, where we had to adapt and make things simpler? Or maybe a time when we went too far in simplifying and had to backtrack?

Moji
Yeah, I don’t know if it’s exactly what you're looking for, but here’s a scenario we had. It's related to the discussion about monolithic versus microservices.

We had this engine that was handling the logic around how a waiting room or queue should behave—like, when it starts, what conditions apply, all that logic. And we also had logic for how the waiting room should look—the presentation layer. We call it the “custom theme”.

Then we said, okay, these are two different responsibilities. Should we separate them? And we did. That was great. We created two modules—people could develop and deploy them separately. Nice setup.

But at some point, we added more components. We used a third-party tool to manage flags—what features are enabled on the presentation side. Then we hit a problem: in production, that service wasn’t responding fast enough. Because we had introduced a new dependency.

So we decided—that doesn’t work. We had to rethink it. We still kept the separation between the presentation and logic layers, but for the presentation part, we removed that external dependency. We built the flag handling into the service itself to make it more self-contained.

But we paid a price. I remember we had to run a big load test, and during that test we realized it wasn’t going to work as it was. So we iterated and improved the design. The project was delayed by about a month, but it was worth it.

Jose
Okay. I think examples like that are really helpful. Do you have other examples where you saw complexity becoming a problem?

Moji
Hmm. When we say “complexity,” my mind goes straight to dependency. But maybe another type of complexity is in the logic.

I’d say something more general—I see this a lot in daily development. As engineers, we’re pretty good at overengineering things. People say this about us, and they’re right.

There was a time we were trying to find a bug or understand why a specific scenario was happening. I was talking to one of my colleagues—he had created a really well-structured, complex system with great architecture.

But then we sat down and asked, “Do we really need this?” We just needed a small piece of code to handle a specific case. Did we need 10 components? Did we need full modularity?

In the end, we simplified it. The development effort dropped to one-tenth of what it would have been. And it wasn’t a part of the system that needed high resiliency—it was more like a proof of concept.

So, long story short, yes—I see complexity as often stemming from overengineering. I run into it all the time.

Jose
Yeah, that sounds like it's also kind of your mindset—you're thinking about complexity on one end and simplicity not only in architecture and development, but also in terms of processes.

Moji
A hundred percent. Yeah. I would say I’m kind of accused of not being very process-oriented, generally. But for me, having really nice processes is something I’ve had to learn—coming from a startup like Queue-it, where we were just 10 people working together every day, and now we’re over 200.

So, you need processes—but at the same time, when you make them too complex, you kill the innovation. You also make development time a lengthy process. You end up needing 10 different meetings just to move things forward.

Sometimes I just want to say, “Let’s sit down, get to the whiteboard, and simply talk through the business.” It’s not even about technical stuff. I’ve been in meetings related to product features, even sales conversations, and when they get too technical or too complex, the process becomes slow and fragile.

Jose
It’s trade-offs again, right? Not overengineered, but not too loose either—or not even there at all. I think that’s part of the growing pains that come with scaling.

Moji
Also case by case. In some scenarios, like a POC, being too loose might be okay. Speed might be more important. That trade-off is something we engineers need to get better at—we need to practice that skill.

Jose
Yeah. I was thinking we should move into some rapid-fire questions. Just answer what comes to mind—keep it short.

Moji
Is it GDPR compliant?

Jose
Well, hopefully! GDPR—depends. I don't know if you’ll share any personal or PII data… hopefully not.

Moji
No IPs. No IPs.

Jose
No IPs. First question: Scalability is...?

Moji
Simplicity.

Jose
There we go. Another one—do you have any resource you’d recommend to listeners? A book, podcast, blog, or a person that inspires you in this area of simplicity and scalability?

Moji
It’s a bit old school, but Martin Fowler was one I always looked up to. But mainly I learn by looking around, using critical thinking. That always helps—not just following whatever is trending in the engineering world.

It’s more about asking, “Does this really make the system scalable in this specific scenario? Is it a best practice for my use case?” Every industry and application has its own specifics, so you need to customize best practices to your context.

Jose
And I have a feeling you might’ve already answered the next one, but just in case—what advice would you give to your younger self, early in your career?

Moji
I’d go one step back. The first industry I worked in was very data-oriented—it was for an insurance company back in Iran. The data had to be fully consistent. There was no room for eventual consistency.

Then I joined Queue-it, and started working with great minds here. That’s when I was introduced to things like eventual consistency and scalability. It was tough at first, but I learned a lot.

So I’d say—don’t just follow the trend. Always compare ideas. Trends might be popular, but that doesn’t mean they fit every scenario. It might be hard to convince others in the moment, but eventually people recognize when an approach actually works better.

Jose
Last question, Moji—any technology that excites you these days?

Moji
Hmm. Everyone’s talking about AI, but for me, I’m more into things related to distributed data, consistency, eventual consistency. I’m excited about NoSQL databases that can be easily distributed.

It’s an old topic, I know, but it still fascinates me—how fast data can be distributed. And for us at Queue-it, it’s important. We’re actively working on building systems that are distributed across data centers. That’s a very interesting topic for us.

Jose
Very cool. And that might be a topic we’ll want to revisit in a future episode. Maybe we’ll have you back for that.

Moji
For sure. I’d enjoy that.

Jose
Thanks so much, Moji.

Moji
Thank you.

Jose
And that’s it for this episode of the Smooth Scaling Podcast. Thank you so much for listening. If you enjoyed it, consider subscribing—and maybe share it with a friend or colleague. If you’d like to share any thoughts or comments, send them to smoothscaling@queue-it.com.

This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner.

I’m your host, José Quaresma. Until next time—keep it smooth, keep it scalable.

[This transcript was generated using AI and may contain errors.]