System Architecture: Straight Facts, In Order
1. What Is System Architecture?
• The structure and behavior of a system.
• Describes components, their interactions, and the technologies used.
Think of it like a building blueprint, but for software/hardware systems.
2. Basic Types of System Architecture
a. Monolithic Architecture
• All components tightly integrated.
• Example: Early desktop applications like Microsoft Word (pre-cloud).
• Pros: Simple to develop, deploy.
• Cons: Hard to scale, maintain, or update.
b. Client-Server Architecture
• Client requests data; server responds.
• Example: A web browser (client) fetching a web page from a server.
• Pros: Centralized control.
• Cons: Server becomes bottleneck.
c. N-Tier Architecture (Multi-Tier)
• Layers split into presentation, business logic, and data.
• Example: Web app: Frontend (React) → Backend (Node.js) → Database
(MongoDB).
• Pros: Separation of concerns.
• Cons: Higher complexity, latency.
3. Modern System Architectures
a. Microservices Architecture
• App broken into small services, each doing one job.
• Communicate via APIs (often REST or gRPC).
• Example: Netflix - search, playback, billing are all separate services.
• Pros: Scalable, independently deployable.
• Cons: Complex deployment and testing.
b. Serverless Architecture
• No server management. Functions triggered by events.
• Example: AWS Lambda function triggered by file upload to S3.
• Pros: Cheap, scales automatically.
• Cons: Cold start latency, vendor lock-in.
c. Event-Driven Architecture
• Components communicate through events.
• Example: E-commerce app: Order placed → Inventory updated → Email
sent.
• Pros: Decoupled, real-time processing.
• Cons: Hard to trace/debug.
4. Key Components of System Architecture
• Frontend (Client): User interface; e.g., mobile app, web browser.
• Backend (Server): Business logic and APIs.
• Database: Stores data; e.g., PostgreSQL, MongoDB.
• APIs: Define how components talk; e.g., REST, GraphQL.
• Load Balancer: Distributes traffic evenly.
• Cache: Stores frequently used data; e.g., Redis.
• Queue: Manages tasks; e.g., RabbitMQ, Kafka.
5. Deployment Architectures
a. On-Premise
• Servers in-house.
• Example: Banks hosting sensitive data in local data centers.
b. Cloud-Based
• Hosted by providers like AWS, Azure, GCP.
• Example: Startups deploying via AWS EC2, S3, Lambda.
c. Hybrid
• Mix of on-prem and cloud.
• Example: Healthcare app with sensitive data stored locally but using cloud
for less critical services.
6. Architecture Diagrams
• Purpose: Visual map of components and flows.
• Include: Clients, APIs, Services, DBs, 3rd-party integrations.
• Use: UML, C4 model, Lucidchart, Draw.io.
7. Design Principles
• Scalability: Can it handle growth?
• Availability: Will it stay online?
• Maintainability: Easy to update/fix?
• Security: Safe from threats?
• Performance: Fast response times?
8. Common Patterns
• MVC (Model-View-Controller): Web frameworks (e.g., Django).
• CQRS (Command Query Responsibility Segregation): Write and read
operations are separated.
• Pub/Sub: Services subscribe to events (e.g., Google Pub/Sub).
• Service Mesh: Manages service-to-service communication (e.g., Istio).
9. Architecture Review Checklist
Clear separation of concerns
Scalable components
Fault tolerance & redundancy
Logging and monitoring
Secure APIs & data handling
CI/CD pipelines
DEEPSEK
What is System Architecture?
• Definition: The high-level structure of a system, including components,
relationships, and design principles.
• Goal: Ensure scalability, reliability, security, and performance.
Example:
• Monolithic (all features in one codebase) vs. Microservices (split into
independent services).
2. Key Architectural Styles (Timeline & Examples)
a) Monolithic Architecture (Old School)
• Era: 1990s - Early 2000s
• How it works: Single codebase, tightly coupled.
• Pros: Simple to develop/deploy.
• Cons: Hard to scale, single point of failure.
• Example: Legacy Java EE apps (e.g., old banking systems).
b) Client-Server (1990s - Present)
• How it works: Client requests ↔ Server responds.
• Example: Web apps (Frontend = Client, Backend = Server).
c) Service-Oriented Architecture (SOA) (Early 2000s)
• How it works: Loosely coupled services (e.g., via ESB - Enterprise Service Bus).
• Example: Amazon (early days) used SOA for modular services.
d) Microservices (2010s - Present)
• How it works: Small, independent services (APIs).
• Pros: Scalable, fault isolation.
• Cons: Complex, needs DevOps.
• Example: Netflix, Uber (each feature is a microservice).
e) Serverless (2015 - Present)
• How it works: Run code without managing servers (e.g., AWS Lambda).
• Example: Slack bots, event-driven processing.
3. Key Components in Modern Systems
Component Purpose Example Tech
Load Balancer Distributes traffic NGINX, AWS ALB
API Gateway Manages API requests Kong, Apigee
Database Stores data SQL (PostgreSQL), NoSQL (MongoDB)
Component Purpose Example Tech
Cache Speeds up reads Redis, Memcached
Message Queue Async communication Kafka, RabbitMQ
CDN Faster content delivery Cloudflare, Akamai
4. Real-World System Design Example: Instagram
1. Client: Mobile app (iOS/Android).
2. Load Balancer: Distributes traffic.
3. App Servers: Handle posts, DMs, stories (microservices).
4. Database: PostgreSQL for users, Redis for stories.
5. CDN: Delivers images/videos fast.
6. Message Queue: Kafka for notifications.
5. Trending Architectures (2020s)
• Event-Driven: Reacts to events (e.g., Uber ride requests).
• Edge Computing: Process data closer to users (e.g., IoT devices).
• Blockchain: Decentralized systems (e.g., Ethereum).
Final Tips
✔ Start simple (Monolith → Microservices).
✔ Use caching (Redis) for high-read systems.
✔ Decouple services (Kafka for async comms).
✔ Plan for failure (Circuit breakers, retries).
