Architecture today

For a while now, microservices seem to dominate everything, and with them, FastAPI in Python. The adoption of the cloud as infrastructure in almost every company points in that direction. However, the most obvious downside of this approach is managing and orchestrating those microservices; you have to be very careful with the dependencies between them so you don’t “cross the wires”. You need highly skilled people to keep these operations running.

That said, microservices have become the standard. Tools have emerged to make them easier to use, like containers, Kubernetes or Prometheus, and they offer a ton of advantages that can leave a technology like Django behind. It’s slow, or at least on the surface, whereas FastAPI is fast, both when processing requests and when developing with it. It also includes typing almost “for free” (something Python really benefits from, like JavaScript needed it) and has an extremely robust dependency system.

On the other hand, Django has been around since 2005; it’s almost as old as Facebook. It stays relevant thanks to a well-organized community that is passionate about web development. As a result, a large share of the usual problems of programming for the web are already thought through and solved. It comes with “batteries included”, a term that means a big part of your solution is ready from the start (authentication, admin panel, ORM, security, templates and routing). The problem is that its philosophy doesn’t align as well with this microservices trend, since it comes from an era when the monolith shined: the application as a centralized whole, with a server-side orientation.

Still, Django has important downsides. It looks slow and, back in the day, there was no way to make asynchronous calls (something that would seem crazy today). In terms of scalability it can fall behind, even with its modular monolith structure and per-app deployment. Also, Django has a strict, opinionated way of working. It can be overkill for small projects. All of this leads us to its learning curve, which is steeper than that of its alternative.

With that said, I’d like to dig deeper and analyze the different dimensions from the business perspective, which are what will ultimately lead us to decide between one tool or the other.

Time To Market

We need to be clear about the business priority when launching the MVP: What is the product about? Does it need to manage users, roles or some kind of common administration? Or, on the contrary, is the execution speed of each call in a specific service more important? These questions guide us. If the solution requires managing users, passwords, moderating content or having some kind of administrative support, with FastAPI you’ll have to build all of this from scratch and timelines will increase significantly.

On the other hand, if you need to stay in sync with frontend or mobile teams, FastAPI will give you the smoothness. Its interactive documentation and how quickly you can prototype routes ready for the frontend team to consume speed things up incredibly.

It’s also ideal for validating ideas and exploring markets with a very specific tech service. We’re talking about something so concise that Django’s robust infrastructure would only get in the way.

Budget and Team

With no team and no budget, Django shines. With very little, we can do a lot. And if you add AI agents on top of that… in the same codebase and practically natively. A single developer can handle a big solution, moving from the database all the way to the visualization and the interface.

However, we have to remember: jack of all trades, master of none.

The story changes if you have a structured development department, with at least one team dedicated purely to the frontend, several developers and the resources to invest the time it takes to “reinvent the wheel” again. Although, let’s be honest, it will be a much more specific and faster wheel. At the end of the day, if we’re competing in Formula 1, I wouldn’t recommend driving a pickup truck.

Product vision

Are we building a heavy, centralized platform, or a product that will be part of an ecosystem of services? If the business value lies in convoluted rules and in managing structured data, Django is most likely the right direction. On the other hand, if the value lies in processing speed, concurrency and independence, maybe it isn’t. You have to stop and think: how do I see this solution in 2 or 3 years? Things to keep in mind:

• Relational complexity
• Centralization
• Technical specialization
• Interface independence

Scalability

At first glance, this fight comes down to synchronous vs. asynchronous. FastAPI is async by default, and microservices grow much better than monoliths. However, in reality, giants like Instagram, Pinterest and Patreon started (and to a large extent still operate) with Django. Saying that Django can’t handle large numbers of users is simply not true.

The real question is: does that massive traffic happen at exactly the same moment? If the challenge goes beyond just “holding up” under more users and centers on real-time interaction between them (like a live chat or a multiplayer game), FastAPI is the right call so the architecture doesn’t wobble.

Agility

In these terms, a few years ago Django was an undisputed star; it saved us a lot of time by letting us do more with less code. Today, with AI agents spitting out code like machines, this “batteries included” feature loses a bit of weight. Now we can achieve the same thing using smaller tools.

However, Django has evolved and found a new niche of value: standardization and keeping chaos under control.

A less experienced engineer is much more likely to end up with a chaotic, incomprehensible codebase using a tool like FastAPI than using Django, since the latter tells you step by step how to structure things. Many frameworks do this (like Ruby on Rails or NestJS): they put up “guardrails” so you don’t go off the road. Writing code with AI means that today, more than ever, we have to care about maintainability and technical debt.

KISS

At the end of the day, to choose correctly we can narrow it down to knowing where we are, who we are and where we’re headed.