When you build an application, one of the first big decisions is its architecture. How will you organize the code? For a long time, the standard was the monolith. Imagine a single, large building where every department—sales, marketing, engineering—works under one roof. The entire application is a single, unified unit. All its features are developed, deployed, and scaled together.

The alternative is a microservices architecture. This is like having a campus of smaller, specialized buildings. Sales has its own building, marketing has another, and so on. Each service is a self-contained application with its own database and logic. They communicate with each other over a network, typically using APIs. This modularity allows teams to work independently and scale specific parts of the application without affecting the whole.

There's no single right answer; it's all about trade-offs. Monoliths are simpler to develop and deploy initially. But as they grow, they can become a Big Ball of Mud, making updates slow and risky. Microservices offer flexibility and scalability but introduce the complexity of a distributed system, where you have to manage network communication, data consistency, and service discovery.

When your application gets popular, you need to handle more traffic. This is where scaling comes in. There are two primary ways to do it.

Vertical scaling, or scaling up, means adding more power to your existing server. Think of it like upgrading your laptop with a faster CPU, more RAM, or a bigger hard drive. It's simple and can be effective up to a point, but you'll eventually hit a physical limit. You can only make one machine so powerful.

Horizontal scaling, or scaling out, means adding more servers to share the load. Instead of one powerful machine, you have a fleet of smaller ones working together. This approach is highly flexible and forms the backbone of most large-scale web services. A load balancer is used to distribute incoming traffic evenly across the servers.

Horizontal scaling is a natural fit for microservices. If your payment service is getting hammered during a holiday sale, you can just spin up more instances of that specific service without touching the user profile or product catalog services.

Traditional architectures require you to manage servers, whether they're physical machines or virtual instances in the cloud. You have to provision them, patch them, and make sure they're running. Serverless computing abstracts this away. You write your code as individual functions and the cloud provider handles the rest. The code only runs when it's triggered, and you only pay for the computation time you use.

This pairs powerfully with edge computing. Instead of running your code in a few large, centralized data centers, edge computing runs it in many smaller locations around the world, closer to your users. When a user in Tokyo makes a request, it's handled by a server in or near Tokyo, not one in Virginia. This dramatically reduces latency, which is the delay between a request and a response.

The combination, often called the 'Serverless Edge,' gives you the best of both worlds: the low-latency performance of a global network and the operational simplicity of serverless functions. This is the direction modern web applications are heading.

In a distributed system, data is spread across multiple machines. This introduces a fundamental challenge: how do you keep everything in sync while also ensuring the system stays available and handles network failures? The CAP theorem provides a framework for thinking about these trade-offs.

The theorem states that a distributed data store can only provide two of the following three guarantees:

• Consistency: Every read receives the most recent write or an error. All nodes in the system see the same data at the same time.
• Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
• Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

Because network partitions (failures) are a fact of life in distributed systems, you must have Partition Tolerance. Therefore, the real trade-off is between Consistency and Availability. Do you want your system to always return the correct, most up-to-date data, even if it means some requests might fail or time out (CP)? Or do you want your system to always be online, even if it means it might occasionally return stale data (AP)?

Your choice of database often comes down to this trade-off. A banking application needs strong consistency, while a social media feed might prioritize availability.

Time to check your understanding of these core architectural concepts.

These architectural decisions are the foundation of any robust, scalable application. Understanding the trade-offs is the first step toward moving from writing code to engineering systems.