Tech VocabularySoftware architecture describes how an application is organized, how different parts fit together, communicate, and stay running when things go wrong. Architecture decisions directly impact how fast you ship features, what breaks when things go wrong, how much infrastructure costs, and who you need to hire.
The monolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices.: one big application
A monolithic architecture is a single codebase where everything lives together, authenticationWhat is authentication?Verifying who a user is, typically through credentials like a password or token., payments, order management, notifications, admin dashboard, deployed as one unit. Think of it like a single food truck: simple to manage, but if the fryer breaks, nothing gets served.
Why teams choose monoliths
- Simplicity: One codebase, one deployment, one technology stack
- Speed for small teams: Move fast without coordinating between services
- Easier testing: Test the entire application in one go
- Lower operational overhead: Deploy, monitor, and debug one thing
When monoliths become painful
- Deployment risk: A bug in email notifications could bring down payments
- Scaling challenges: Must scale the entire application even if only one feature is busy
- Team coordination: 50 developers in one codebase means constant merge conflicts
- Technology lock-in: Stuck with the language and framework chosen years ago
MicroservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data.: breaking it apart
Microservices architecture splits an app into independent services, each responsible for one capability: authenticationWhat is authentication?Verifying who a user is, typically through credentials like a password or token., payments, notifications, catalog, orders. Each service has its own database, codebase, and deployment pipelineWhat is pipeline?A sequence of automated steps (install, lint, test, build, deploy) that code passes through before reaching production.. They communicate through APIs.
Think of specialized food stations instead of one truck: if the pizza oven breaks, people still get drinks and desserts.
Why teams choose microservices
- Independent scaling: Payment service hammered on Black Friday? Scale just that service
- Team autonomy: The payments team deploys without coordinating with search
- Technology flexibility: Notifications in Python, payments in Java, each team picks the best tool
- Fault isolation: If recommendations crash, users can still browse and buy
The microservices tax
- Operational overhead: Monitoring 20 services instead of one
- Debugging difficulty: Bugs bounce between 5 services
- Data consistency: Keeping data synchronized across services is hard
- Network complexity: Services talk over unreliable networks
- Team expertise: Need engineers who understand distributed systems
ServerlessWhat is serverless?A hosting model where individual functions run on demand and the platform handles all server management, scaling, and uptime for you.: forgetting about servers
With serverless computing (Function-as-a-Service), you write small functions and the cloud providerWhat is provider?A wrapper component that makes data available to all components nested inside it without passing props manually. (AWS Lambda, Google Cloud Functions, Azure Functions) handles starting servers, shutting them down, scaling, and patching.
When someone uploads an image:
1. Trigger my resize-image function
2. Create thumbnail versions
3. Save to cloud storage
4. Send me the bill for compute time usedNo uploads for an hour? You pay nothing. 10,000 uploads at once? The platform scales automatically.
Why teams choose serverless
- No server management: No patching, capacity planning, or 3 AM alerts
- Automatic scaling: Zero to thousands of requests instantly
- Pay-per-use: Pay for 100ms of compute, not 24/7 idle servers
- Rapid development: Perfect for prototypes and features with spiky traffic
Serverless limitations
- Cold starts: First request is slow if the function hasn't run recently
- Execution limits: Functions typically can't run longer than 15 minutes
- Vendor lock-inWhat is vendor lock-in?When your code depends on features unique to one platform, making it expensive or difficult to switch to a different provider.: Code tightly coupled to the cloud provider
- Debugging difficulty: Harder to troubleshoot without environment control
Comparing the patterns
| Aspect | Monolith | Microservices | Serverless |
|---|---|---|---|
| Complexity | Low | High | Medium |
| Initial speed | Fast | Slow | Very fast |
| Scaling | Scale everything | Scale individually | Automatic |
| Team size | Small (2-10) | Large (20+) | Any |
| Cost model | Always on | Always on | Pay per use |
| Best for | MVPs, startups | Large products, many teams | Spiky workloads, events |
| Operational burden | Low | High | Low |
There's no perfect architecture, only the right fit for your team's size, skills, and product stage. Moving to microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. might slow development initially but enable faster shipping later. Going serverlessWhat is serverless?A hosting model where individual functions run on demand and the platform handles all server management, scaling, and uptime for you. saves money but adds debugging challenges. Understanding these tradeoffs helps you participate in architecture conversations with your engineering team.