Thinking Like an Architect

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Remember when software architecture seemed like just boxes and arrows on a whiteboard? In this talk, we'll challenge that view and explore what really matters in modern software design. You will discover how successful architects think beyond tech specs, seeing architecture as a living story shaped by people, teams, and evolving needs. You'll gain fresh perspectives on building systems that last and learn why the best architectures are more about enabling people than enforcing technical decisions. Join me for a journey that might just change how you think about architecture forever.

This talk has been presented at Node Congress 2025, check out the latest edition of this JavaScript Conference.

FAQ

A common misconception is that software architecture is merely about choosing the right tech stack. In reality, it involves making informed decisions, balancing trade-offs, and dealing with long-term consequences.

Architecture should be viewed as a mindset rather than a title. It involves understanding the context, making informed decisions, and adapting to changes over time.

Context is crucial in software architecture because designing a system that aligns with business needs and organizational structure helps the system thrive.

Event storming and domain storytelling are two techniques that help team members understand business needs by focusing on user behavior and system interaction, rather than technology.

Understanding architectural characteristics, such as security requirements and latency, is essential for designing a system that meets specific business needs and operational constraints.

Modularization can take various forms, from monoliths to microservices, and should be chosen based on the rate of change of features and the need for independent development and iteration.

Communication, inclusion, and documentation are core skills in architecture, allowing architects to effectively convey ideas and build bridges between technical and business teams.

Architects should prioritize areas that provide the most business value, even if it means accepting technical debt in less crucial areas, to ensure strategic goals are met.

The ultimate goal is to create adaptive architectures that can evolve over time, rather than ones that are intended to last forever without change.

Modern developers need to consider multiple aspects such as DevOps, architecture, security, and more, as they take on a variety of tasks due to the shift-left movement.

Luca Mezzalira
Luca Mezzalira
31 min
17 Apr, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Available in Español: Thinking Like an Architect

1. Introduction to Architecture

Short description:

In modern software development, developers have more to think about, including DevOps, architecture, and security. Architecture is not just about selecting the right tech stack; it involves decision-making, balancing trade-offs, and dealing with consequences. It should be considered a mindset rather than just a job title. The speaker, Luca, shares 11 insights based on their experience in various roles and organizations. They emphasize the importance of understanding the problem space, not just focusing on technology, and considering the context of the business and organization. Architecture is directly linked to engineering culture and organization.

In modern software development, we changed the way how we were used to design software. But the real challenge is now developers have way more things to think about. Think about the DevOps part, the architecture, security, and so on and so forth. This shift left movement started to kick in very aggressively towards developers, and now they need to cover a variety of tasks.

The challenge with architecture is that very often people think that architecture is nothing more than selecting the right tech stack or the most bleeding-edge tech stack. Unfortunately, this is wrong. Because the reality is that architecture is composed by three simple things. You take some decisions based on the context and the information that you have, then you need to balance the trade-offs regarding the decision you need to make, and finally, dealing with consequences. Because the reality is, architecture is not something you decide and then you forget about that. You need to live with that for a long period of time very often.

Therefore, architecture is not defined as a title, in my opinion, but like a mindset. If you have the architect role inside your job title, you might or might not represent a good architect. During this talk, I want to share with you 11 tips that I learned in the trenches in the past 22 years. My name is Luca and I'm working currently for AWS. But in the past, as you can see, I have done quite a few roles that started from a simple developer up to a CTO and everything in between. I had the pleasure to work with a large organization, Unicorn, companies that move from zero to millions of customers and stuff like that.

I believe that these 11 insights will help you to rethink how architecture should be thought inside your system. Let's start first with the problem space. We need to understand that. In modern architecture, one thing that changes is the decentralization part because we are not decentralizing anymore, just the practices, the engineering practices to multiple teams that are working on a specific area of the system, but also the organization. But for the vast majority of the time, the organization is an afterthought. We think that with a simple architecture like microservices or a self-based architecture, whatever, we solve all our problems. That's not the case. The second problem is that we focus a lot on the technology. We ignore the business needs and we focus on what we are passionate about, writing code or building with the latest cloud service. And lastly, we ignore our context, what the business needs. So what are the technical skills inside our organization and how our organization is structured and so on and so forth. Our context is the king here because if we design something that helps our context to thrive, then therefore we are in a good situation.

So let me start with a few tips that I learned in the trenches in the past 22 years. So first of all, you need to remember that architecture is linked, directly linked to engineering culture and organization.

2. Considerations for System Design

Short description:

Selecting a monorepo versus a polyrepo shape team communication. Technical decisions should not be underestimated, as they define team workflow and communication. Understanding product/business needs and gathering user feedback are crucial. Collaborative workshops like event storming and domain storytelling focus on business understanding. Start with boundaries to define core, supporting, and generic domains.

Something as simple as selecting a monorepo versus a polyrepo approach will basically shape the way how your teams are communicating together. And that's not something that you can underestimate. Very often people think that it's just a technical decision. The reality is you are basically defining how your teams should work, maybe using trunk-based development. Do they have the skill for doing that or how much friction you will create inside the trenches and also how they are going to communicate. Because sharing with the monorepo is different from sharing with the polyrepo approach and so on and so forth.

So never underestimate a technical decision to think that is just living in that realm. The other thing that you need to think about is understanding what your product or business needs. This is the first point for me. And very often, either that you're working in a Greenfield project or a Brownfield project is underestimated. It's extremely important we understand what kind of KPIs do we need to track? What is the benefit of this feature for our users? Why we are doing that? What is the minimum valuable product that they can deliver as soon as possible in order to gather information from the users?

There are two techniques that I usually use with customers now with AWS but before also in my company. One is a collaborative workshop called event storming that drags a bunch of people inside the same room and starts to take a step back from technology and looking on the business and how your users will behave inside the system. The other one is domain storytelling, very similar but with different approach where we tell a story and we explain how our users are going to interact with our system. But both of them have something in common. They don't need to talk about technology that at the beginning is not needed. You need to understand what you need to express inside your system.

And that leads us to the second tip. So start with boundaries. When you understand how the system works then you start to think about how your boundaries look like. Domain driven design is phenomenal on that because usually it helps to create a common vocabulary between product and engineering. But more importantly, when you identify through event storming on domain storytelling the different boundaries that your system is composed to or your feature is composed to, you can start to categorize them. You can define what is core, so the most important things inside your system. What is supporting that helps core to thrive and what is generic. Let me give you an example. So if we take Netflix for instance, a core domain for Netflix, so the reason why Netflix exists is allowing you to watch your favorite series in any device and at any given point of the day. The supporting domain, for instance, could be personalization. And personalization means that if I have a catalog that is the core domain and I have a personalization, yeah, I can have a better experience. But the reality is if the personalization service is down, I can still watch the catalog, I can still search. So it's not too bad. So I can immediately start to apply characteristics to supporting domains.

3. Architectural Considerations

Short description:

Generic domains are necessary for system functionality. Regularly revisit boundaries to align with evolving business and architecture. Identify architecture characteristics, such as security requirements and latency considerations. Modularize your system based on context and requirements, considering different architectural techniques like monolith or microservices.

That is the same for generic. In order to consume video on Netflix, you need to subscribe. And in order to subscribe, you need to pay a fee with, I don't know, PayPal, my credit card or whatever other payment method that you want. Netflix is not a payment gateway, but they leverage an integration in order to do that. That is a generic domain that does not add any value to Netflix itself, but the reality is it's needed in order to have the Netflix service available to you.

Moreover, remember, if you're working on a brownfield project, you need to also revisit regularly your boundaries, because your business is evolving as well as your architecture. Because the reality is that if you ignore that the business is taking a direction and then you start to arise friction in the trenches, you cannot blame the architecture. So you just need to revalidate that the boundaries are still valid in the way and the form that the company wants to go. The other thing is that you need to, as a third part, you need to identify your architecture characteristics.

Because very often, I speak with companies and teams that are starting to ask, oh, look, what do you think about this? It's like, perfect, so let's try to understand what you need to express here. What are your security requirements? What is your SLA? Are you affected by latency? And so on and so forth. Let me give you an example. So if you think about latency, for instance, if you're working on, I don't know, a financial system that deals with the stock market, definitely latency matters. You cannot design something that has a lot of hops between the network in order to increase the latency. Probably you need to think about co-locating certain things. And there are some interesting case studies that shows that for specific things where latency is mandatory, we need to design things differently.

While I think about another requirement, like for instance, the availability, you need to think about how many nights you want. Because the reality is designing a thing with, I don't know, three nights of availability, it means that you are going to have a certain more or less an hour of potential downtime inside your system. Is it acceptable or is not? And if it's not, you need to think about using a multi-regional strategy. So those kind of decision or architectural characteristics that you need to implement inside the system are mandatory to understand because otherwise you cannot design properly your system. There are certain things that will be immediately filtered out when you have clarity on your architectural characteristics.

Now, the other thing when you have done that is understanding how you could modularize your system. So there are different techniques in architecture, right? So we can start with monolith, modular monolith, or microservices, or even a self-based architecture. And all of them are not right or wrong. We need to stop this fight thinking, oh yeah, microservices are not great for this reason, that reason, that reason, or monolith are for the past. There are situations where you need to optimize, for instance, for retrieving, gathering feedback fast from your users. And maybe a monolith could be the answer. There are other situations where your context tells us that you need to have multiple teams working together, but they cannot always depend on each other. So you want to reduce external dependencies. And therefore, in order to express that, you might use a microservice architecture.

4. Architectural Flexibility and Scalability

Short description:

Consider the rate of change for specific features and adapt the level of granularity accordingly. Be pragmatic and flexible in choosing between architectural approaches. For event-driven systems, leverage infrastructure and consider trade-offs for scalability. Use techniques like CDC for triggering events and optimize cost while maintaining benefits. Consider using a cron job for batch processing, but be aware of increased costs and resource requirements.

So when you think about how granular you want to go, and that is not only for the design of the architecture, it could be also the code wise, start to think about what is the rate of change of a specific feature. If you have a feature, for instance, that you know that there is a high rate of change at the beginning because you need to build from scratch, but then they are going to change once or twice per year. So the for is keeps the lights on on this feature. Then probably you can even allow you to co-locate more, while on the other side, if you have something to change very often, you might need to think very well on the way how to encapsulate your service. So you can change independently, reducing, not eliminating the external dependencies and start to, let's say, work more on fast iteration. And as you can see now, the idea of I have a modular monolith or microservices doesn't add up too much because you don't have to be, let's say, to follow a specific path. And when you decide one thing, you only use that path. It has to be, let's say, slightly more fluid.

Be pragmatic and not dogmatic. Because I give you this example. So imagine that you are working in a system that is, by design, event-driven architecture. So there is a service that you see at the top that is communicating through an event to a system that is sending email and SMS and push notification to all your customers. Now, when you think about the implementation of this service, you can have like a bit of compute, container, serverless, wherever you want. And then you store in a database when you need to notify this user. And maybe you can decide now that through a technique that certain databases have that are called CDC, you can trigger when, let's say, a record expires or changes and start to trigger a specific event for saying, OK, send to the push notification or better send an email. Now, if you think about that, the trade-off here would be that I'm leveraging more the infrastructure and me, as a developer, I have a lot of free time to do something else. That could be a decision that you want to take in this case, right? But at the same time, what happens about scale? So if I have like 100 messages, that's fine. So I send like 100 messages and then I will store 100 record in a database. And then for CDC, I will send 100 times this information to a third party or another service for sending the push notification or email. But what if I have 10 millions? And now it's starting to get slightly more complicated. So I need to rethink my system. If I have 10 millions, it means that probably I can look into how I can optimize cost, but at the same time having the same benefits.

Because if you send a push notification at the end of the day, if you send at the top of the hour or 10 minutes late, no one will complain in certain cases, obviously, if there are certain scenarios that it needs. But let's assume that it's not in this case. And then you can start to think about, for instance, using a cron job. And then every 10 minutes you take the last, I don't know, a certain amount of messages that you need to send and then start to send out. Now, what is the challenge, though? That? Yes, probably the infrastructure will be cheaper. But at the same time, your costs start to raise because you need to write the code, maintain the code, update the code and so on and so forth. You are not a free resource.

5. Holistic Thinking and User Priority

Short description:

Think holistically as an architect and consider the context to make decisions. Embrace the evolutionary mindset and prioritize users' needs. Focus on helping customers reach their goals rather than building a perfect system.

You are not a free resource. And when you think like an architect, you need to think holistically about the plan. Both approaches can work. But the context will drive your decision.

Now, the other thing that you need to think about, even in the previous example, our change in a situation like that would be minimal because we want to have an evolutionary mindset when we are designing our system. The only two constants in architecture are changes and tradeoff. And the funny part for me is that very often I heard, oh, yeah, because we have always done it this way from certain teams.

But unfortunately, you cannot fight that. You need to embrace this because this is what the company wants to have. And we need to think about our users, our customers, because that is the only priority. Our users are the people that are basically buying. They don't care if you have a self-based architecture behind the scene or a monolith. What they care about is they can accomplish a specific task. And therefore, your job is not building the perfect system. We're not here to use only the most amazing technology ever, is to instead help our customer to reach a specific goal. And here the balancing act that we need to do when we think like an architect.

6. Long-Term Vision and Domain Understanding

Short description:

In certain situations, immediate and scrappy solutions may be necessary due to key constraints and deadlines. However, it's important to work on long-term implementations and make tradeoffs. Adopt a lean mindset and make decisions at the last responsible moment. Understand your domain, consumers, and the system to make better decisions. Take a holistic view step by step.

So what is the long term vision? What is the immediate needs? There are certain situations that happened to me several times where, for instance, I had to integrate and import a bunch of more or less like half a million users from one platform to another platform. Now we could do the right things or we can do let's say the immediate and scrappy way. And we went with the scrappy way for one reason, there was a key constraint, there was a deadline for the beginning of the football season and then surprise and you cannot move it. And therefore, yes, I bargain with the business that we will do the quick win. But at the same time, right after we start to work on the long term implementation, because those are the things that you need to deal with tradeoffs, as we said before.

And very often when you do this kind of decision, you need to take a lean mindset. So take the best decision that can at the last responsible moment. And I can guarantee you that if you stay in the procrastination mode, the starting to think or need to gather more information than they need more information, you are going to in a rabbit hole that they are not going to move the final decision too much. When you have enough, you can start to change. And if you use an evolutionary mindset, you can evolve over time.

So therefore, as a developer or tech lead, what you need to do for me, for thinking like an architect, are three things. So the first one is you need to have a great understanding of your domain. At the end of the day, you're working inside your domain. But you need also to understand your consumers, that is something that they didn't see very often. What do they want? What kind of new features are building? Do they want me to design an API? Better stuff like that. And finally, you need to have a bigger understanding of the system. If you start today in a new company and you want to start understanding your system going this direction, because when you have an holistic idea of the system, you can take better decision inside your domain. But you don't have to rush into that. You need to master first what is closer to you and then you take, let's say, a more holistic view step by step.

7. Communication, Inclusion, and Documentation

Short description:

Communication, inclusion, and documentation are core architecture skills. Effective communication is crucial for architects to influence system design. Understand the social-technical aspects and adjust your language when communicating with different stakeholders. Share your reasoning and involve others in the decision-making process. Documentation tools like architectural decision records, requests for comments, and diagrams can aid in better communication and understanding. Embrace architecture as code to include all stakeholders.

Then the other important things that every architect should have is communication. But not only that. Inclusion and documentation. Those three things for me are at the core of architecture skills.

Back in the days when I didn't have the air, but my beard wasn't too white, communication was called a soft skill. But big spoiler, it's not anymore because the reality is that if you're not able to communicate how you can influence how to design a specific system, the for for me, communication is a core skill.

When I was VP of architecture, one of the key things I was saying to my team is that 70 percent of their time, they should create bridges with the teams and empathy with the teams in order to understand how the things are working. And instead, 30 percent of the time, they should be technical because of their role of an architect is not only writing code or, let's say, thinking about themselves or how to apply the next pattern is understanding the social technical aspect that is basically behind every single system out there.

Therefore, you need to understand how to change your language accordingly. If you are a tech lead or you are a lead on a side of the team, the way how you are talking with your peers and the way you are talking with the C-suite in order to communicate exactly the same message has to be different. The C-suite don't expect to have too much technical jargon. But what they expect is that they understand the business value. So your role as a lead is shifting the gear and transform what is, let's say, a technical implementation into something that the business can understand. And that will enable you to be a more effective communicator.

But more importantly, you will be, let's say, an asset for your company. Now, the other thing that you need to remember when you're when you're talking with your peers is that you don't have to provide always solution. You need to share your reasoning because you in order to arrive to a certain decision, you pass through a certain steps and you have a certain background that other people might not have and probably won't have. But if you are capable to say, OK, so instead of saying this is the solution, period, you start to say, OK, so if we're doing this way and then we're doing that way and then we're doing that way, we arrive to the same solution. Yes, it's taking slightly longer, but everyone will be on board and everyone will support you. More importantly, they can plug into the journey or your train of thoughts properly in order to augment your final decision.

The four four activities that you need to think about when you are thinking about documentation and train of thought and stuff like that is. So first of all, architectural decision record, write it down, because when you write, your brain starts to connect and starts to understand better the problem space and the solution space. Therefore, writing down why certain decisions were made. Requests for comments are perfect for communicating with your peers and also with other teams, the consumers that we mentioned before, in order to evolve your system. Sequence diagrams, I found them super helpful when you are talking with teams, especially if you are a tech lead or whatever, because they are clear to the spot and they describe a portion of the system very in detail. Then you can use other type of diagrams like C4 model. For instance, I'm a big fan of to describe the system end to end from the highest level to the more deep level. And last but not least, there is no excuse anymore to not understand architecture as code. So stuff like Merrimel JS, for instance, is a great asset for designing diagrams through code. So I highly encourage you to master this stuff because that will enable you to include not only the people that have a voice, but also the people that might have a voice, but they are introverts or they are people that are not used to perform very well in front of other people.

8. Democratizing Communication and Prioritizing Value

Short description:

Democratize communication and prioritize what really matters. Understand where the real value lies and make strategic decisions. Adaptive architectures are superior to those that last forever.

Maybe because of lack of seniority or personal things. And instead, if you allow everyone and democratize basically the possibility to provide wisdom and the voice that you will be able to, thanks to these asynchronous communication approaches.

Finally, my 11th tip is to focus on what really matters. One day my CTO told me, remember, Luca, everything is on fire all the time. And since then, I stick it in my head and never forget it because that's the reality. You cannot distinguish every fire, but you need to understand where the real value lies. Therefore, if you are capable to understand, OK, what is how I can move the business needs better if I do this or if I do that. It's basically your role when you are thinking like an architect, because the reality is everyone has something that doesn't work, but not everything is important for the company.

Remember, at the beginning, when I was talking about domain driven design categorization of the subdomains. So core supporting that is your guide that will help you to focus on what really matters. Therefore, don't be afraid to create technical depth that is strategic. So saying and I've done that plenty of times, this part, yes, I'm fine that we are scrappy there. But this part has to be extremely polished, has to perform because the business value is different.

Finally, the best architecture are not the ones that. Stop here is the last slide, sorry about that. I start again. Finally, remember that the best architectures are the ones that are adaptive, not the ones that last forever. That's all I got. I hope that you enjoy that you take some of these tips with you in your next project and enjoy the rest of the conference. I hope that it was helpful and feel free to reach me out anytime.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Understanding React’s Fiber Architecture
React Advanced 2022React Advanced 2022
29 min
Understanding React’s Fiber Architecture
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
The Eternal Sunshine of the Zero Build Pipeline
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.
Remix Architecture Patterns
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Remix Architecture Patterns
Top Content
This Talk introduces the Remix architecture patterns for web applications, with over 50% of participants using Remix professionally. The migration from single page applications to Remix involves step-by-step refactoring and offers flexibility in deployment options. Scalability can be achieved by distributing the database layer and implementing application caching. The backend for frontend pattern simplifies data fetching, and Remix provides real-time capabilities for collaborative features through WebSocket servers and Server-SendEvents.

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.