Software Architecture Basics

Software architecture is like a building's blueprint. It shows how different parts of your product fit together and communicate. Most apps have 3 main layers: the frontend (what users see), the backend (logic), and the database (where data lives).^[1]

Good architecture makes products reliable, fast, scalable, and maintainable. Bad architecture causes crashes and slow loading times. For example, Netflix serves millions of users because its architecture splits video streaming, recommendations, and user profiles into separate systems that work together smoothly.

As a PM, you don't need to code these systems. But understanding basic patterns helps you estimate timelines, spot technical risks, and ask the right questions during planning.

A monolithic architecture is like a Swiss Army knife with everything packed into one tool. Facebook started as a monolith where likes, posts, and messages lived in one codebase. It's simple to build and deploy, but changing one feature means redeploying everything.

Microservices split functions into separate services. Amazon uses microservices: the cart, payments, and recommendations are independent services. Each team can update their service without affecting others. However, this means your organization is now managing dozens of services instead of just one.^[2]

Startups often begin with monoliths because they're faster to build. As they grow, some migrate to microservices for flexibility. Others, like Shopify, keep successful monoliths by investing in good code organization. There's no universal right answer.

Frontend is the part users see and interact with: screens, buttons, forms, voice interfaces like Alexa or virtual reality using devices like goggles and joysticks. Backend is the system that processes data, runs logic, and stores information. Take Instagram, for example. When you upload a photo, the frontend lets you pick the image and shows a loading spinner. The backend checks the file, compresses it, saves it on servers, and updates your profile.

This split speeds up development, improves run time, and security. Spotify’s front applications on iOS, Android, and web apps all share the same backend. So, if the backend team builds a new feature, every frontend app can use it. If the design team changes the interface, the backend code doesn’t need to change

The connection between them is an API (application programming interface). The frontend sends a request with what it needs. The backend responds with the right data, formatted in a way the frontend understands. That’s how both sides stay in sync without depending on each other’s code.

APIs let different systems talk to each other. When you order an Uber, your phone asks "what drivers are nearby?" The server responds with a list. When you book a ride, your phone sends your pickup location.

APIs work through requests and responses. Here are some examples:

• A GET request asks for information, like showing nearby drivers
• A POST request creates something new, like booking a ride
• A PUT request updates existing information, such as changing your pickup location
• A DELETE request removes something, like canceling a ride

These 4 request types are used in REST APIs, the most common type today because they use standard internet protocols. Other API types, like SOAP, follow different rules and structures for exchanging data.

Many companies make APIs available so other apps can use their services. For instance, weather apps rely on weather service APIs, and payment apps often use Stripe’s API instead of building their own payment system. Well-designed APIs are easy to use because they follow consistent patterns and have clear documentation.

Web apps are applications that run in a browser, so they rely on the features and standards supported by each browser. This is why some products work best in Chrome, Safari, or other specific browsers. When planning a web app, it’s important to know which browsers your target users are likely to use, as this affects functionality, performance, and user experience.

Web apps can follow different architectural approaches:

• Multi-page applications (MPAs) load a new page from the server for each action. They are simpler and work well for content-heavy sites but can feel slower.
• Single-page applications (SPAs) load most of the content once and dynamically update the page as users interact. SPAs feel faster and more interactive but require more initial setup and careful handling of browser compatibility and SEO.

Understanding these basics help you make informed decisions about platform support, user experience, and trade-offs in development.

Databases are where your app stores information. SQL databases organize data in tables, like a phone book: everyone has a name, number, and address in the same format. When you create an account on Amazon, your info goes into neat rows and columns.

NoSQL databases store data in flexible formats, so each record doesn’t have to follow the same structure. For example, one record might have just a name, while another has a name, photo, and favorite color. Instagram uses this flexibility because posts can include photos, videos, or both, and not every post has the same data fields. This makes NoSQL well-suited for applications with varied or evolving data.

Developers choose SQL when you need structure (like tracking orders where every order must have price, date, customer). They choose NoSQL when things vary (like user profiles where some people add bios, some don't). Many apps use both.

Cloud computing is like renting versus buying. Instead of buying expensive servers for your office, you rent computing power from cloud providers like Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. When you need more, you rent more. When you need less, you pay less. Also, some companies use more than one cloud provider to reduce risks like downtime or service outages and to take advantage of different providers’ strengths.

Every app needs 3 things: a place to run code, somewhere to store files, and a database for information. Cloud providers offer all 3. Upload a photo? Goes to cloud storage. Check login credentials? Cloud servers handle it. Everything happens on their computers, not yours.

The killer feature is flexibility. Imagine Black Friday traffic hitting your shopping site. With your own servers, you'd crash. With cloud, new servers spin up automatically to handle the load, then disappear when traffic drops. You pay only for those busy hours.

Your first 100 users are easy. Your first million? That's when things break. Scalability means growing without falling apart. It's the difference between a food truck that serves 50 people and McDonald's serving millions daily.

Vertical scaling means upgrading one machine: more CPU, more memory, more storage. It works until you hit a ceiling. No matter how big the server, it can only handle so much. Horizontal scaling means adding more machines. Each takes a share of the load. Need more capacity? Add more servers. Netflix uses horizontal scaling. When millions stream at once, they don't use one supercomputer. They use thousands of regular servers working together. Each server handles some users. More users? Add more servers. This approach has no real limit. The system grows as the audience grows.

Security requires defense in depth — multiple barriers that each handle different attack vectors. When one defense fails, others maintain protection. This redundancy prevents single points of failure from exposing entire systems.

Core protections start with encryption. TLS/HTTPS secures data in transit between clients and servers. At-rest encryption protects stored data. Password hashing ensures that database breaches don't expose user credentials. Each layer serves a specific purpose in the security chain.

Authentication verifies identity while authorization controls access. Modern apps often delegate authentication to specialized providers through protocols like OAuth 2.0. This lets users authenticate with Google or GitHub without sharing credentials with your app. It's more secure and users find it easier than creating another password.

Mobile apps and web apps solve the same problems differently. Websites load fresh from servers each visit. Mobile apps live on phones, storing data locally and syncing when online. This core difference drives every architectural choice.

Mobile apps can work offline. For example, WhatsApp queues messages without internet, sending them when you reconnect. Websites need constant connection. But websites update instantly — fix a bug, everyone sees it immediately. Mobile apps require app store approval and user downloads, making certain types of fixes take days or weeks.

Mobile apps built specifically for iOS or Android (also called native apps) are fastest but need separate code for each platform. Web apps work everywhere but can't access phone features easily. Many companies start with responsive websites (websites that automatically adjust their layout and design to fit different screen sizes, like desktops, tablets, and phone), then build apps when they understand user needs better.