Sytex is a Django monolith. It’s a codebase of over one and a half million lines. The first lines were written back when service architectures were just starting to gain attention. We’ve decided that Sytex will remain a monolith (for now), and here’s our reasoning.

Note the “for now”

Across all aspects of Sytex, we understand that there are right tools for the right time. For instance, we relied on our relational database for text queries until the benefits of a search database became clear.

As a startup aiming for growth, we have to stay alert to the right time to iterate. Everything below pertains to Sytex’s current state, and we’ll likely revisit and possibly change it in the future.

Our three focuses: product, product, product

Even though we’ve been operating for several years, have prominent clients, and good traction, we still consider ourselves pre-PMF. Therefore, our main focus is iterating the product until we find what our customers truly want. Our efforts are directed there, and we’ve noticed that when we divert effort to evaluating new technologies, we lose focus. We perform better using “boring” technologies that we know inside out. This way, we can allocate all our discomfort budget and drive to challenge ourselves into advancing the product. We explore new technologies only when the product demands it or when scale requires it.

We’re a compact team that likes to move fast

When we’re 100 engineers, the monolith will probably get in our way, and it will be necessary to dismantle it. We keep that in mind and strive to maintain testable, modular code. But right now, we find that the advantages of maintaining a monolithic architecture outweigh its disadvantages. We understand that every tech decision involves trade-offs, and we try to evaluate which features benefit or harm us at every step. We remain vigilant to iterate when the time comes.

We’ve stumbled

We have this clarity now after exploring alternatives and realizing that what we thought would accelerate us would actually slow us down. We’re curious and like to experiment. Each experiment teaches us something new. Some lessons permeate our codebase, improving our practices. Others show us that a particular path isn’t the right one (for now).

Specifically

What we like:

• Having a single backend technology that the entire team can feel comfortable using.
• Unified operations, understood by all developers. Configurations are clear to everyone.
• It’s easy to spin up a local environment very similar to production.
• Iterating on features quickly without introducing new “unknowns.”
• The Python/Django stack isn’t the most efficient on the market, but scaling compute capacity is trivial.

What we don’t like:

• Deployments can grow large, increasing the risk of service disruption.
• Integration times increase roughly linearly with the number of features added.
• We can’t scale specific functionalities in isolation, which raises operational costs.