Applying core system design concepts to design different types of apps:

### **1. Social Media App (e.g., Instagram/Twitter)**

**Key Features**:
- User posts, feeds, stories, notifications, and media uploads.
- High read-to-write ratio (users refresh feeds more often than posting).

**Applied Concepts**:
- **Caching**: Cache user feeds and profiles (Redis/Memcached) to reduce database load.
- **CDN**: Serve images, videos, and static assets globally (e.g., profile pictures).
- **Database Replication**: Use read replicas to handle feed-generation queries.
- **Database Sharding**: Shard posts by user ID to scale writes.
- **Async Processing**: Handle notifications (likes, comments) via message queues
(Kafka/RabbitMQ).
- **Rate Limiting**: Prevent spam (e.g., too many posts per second).
- **Horizontal Scaling**: Add API servers to handle traffic spikes.

---

### **2. E-Commerce Platform (e.g., Amazon)**

**Key Features**:
- Product listings, shopping carts, orders, flash sales, and recommendations.
- Traffic spikes during sales or holidays.

**Applied Concepts**:
- **Autoscaling**: Dynamically add servers during flash sales.
- **Load Balancer**: Distribute traffic to prevent server overload.
- **Caching**: Cache product details and prices (e.g., Redis).
- **Database Indexes**: Optimize product search by category, price, or ratings.
- **NoSQL**: Store unstructured data like user reviews.
- **Object Storage**: Host product images and videos (e.g., AWS S3).
- **Microservices**: Split into cart, payments, inventory, and recommendation services.

---

### **3. Real-Time Chat App (e.g., WhatsApp/Slack)**

**Key Features**:
- Instant messaging, group chats, file sharing, and typing indicators.
- Low latency and high concurrency.

**Applied Concepts**:
- **WebSockets**: Maintain persistent connections for real-time updates.
- **Event-Driven Architecture**: Use message brokers (Kafka) to broadcast messages.
- **NoSQL Database**: Store chat history and metadata (e.g., MongoDB).
- **Caching**: Cache recent messages and active user sessions.
- **Compression**: Compress text and image messages to reduce latency.
- **Database Sharding**: Partition chats by user/group ID.

---

### **4. Media Streaming Service (e.g., Netflix/Spotify)**

**Key Features**:
- Video/audio streaming, transcoding, and global content delivery.

**Applied Concepts**:
- **CDN**: Distribute video/audio streams from edge servers.
- **Object Storage**: Store raw and transcoded media files (e.g., S3).
- **Async Processing**: Transcode videos in the background (e.g., AWS Lambda).
- **Compression**: Compress media chunks for adaptive bitrate streaming.
- **Data Replication**: Geo-replicate metadata (e.g., user watch history).
- **Horizontal Scaling**: Add servers to handle peak streaming traffic.

---

### **5. Ride-Sharing App (e.g., Uber)**

**Key Features**:
- Real-time driver-rider matching, location tracking, payments, and surge pricing.

**Applied Concepts**:
- **Event-Driven Architecture**: Process ride requests and driver updates via Kafka.
- **NoSQL Database**: Store real-time geolocation data (e.g., Cassandra).
- **Caching**: Cache driver/rider profiles and frequent routes.
- **Database Sharding**: Split ride data by city/region.
- **Rate Limiting**: Prevent API abuse during surge pricing.
- **Microservices**: Separate ride-matching, payments, and notifications.

---

### **6. Fintech App (e.g., PayPal/Robinhood)**

**Key Features**:
- Transactions, fraud detection, stock trading, and real-time analytics.

**Applied Concepts**:
- **Data Replication**: Sync transaction data across regions for consistency.
- **Redundancy**: Duplicate payment processing services to avoid SPOF.
- **Rate Limiting**: Block brute-force login attempts.
- **Async Processing**: Batch process transactions overnight.
- **Database Indexes**: Optimize queries for fraud detection (e.g., transaction patterns).
- **High Availability**: Multi-region deployments for 24/7 uptime.

---

### **7. Travel Booking App (e.g., Airbnb/Booking.com)**

**Key Features**:
- Hotel/flight searches, reservations, reviews, and dynamic pricing.

**Applied Concepts**:
- **Autoscaling**: Handle traffic spikes during holiday seasons.
- **Caching**: Cache search results (e.g., hotels in Paris).
- **Database Indexes**: Optimize search by price, location, and ratings.
- **CDN**: Serve images of hotels and destinations.
- **Microservices**: Split into search, booking, payments, and reviews.
- **Load Balancer**: Route users to the least busy server.

---

### **8. Collaboration Tool (e.g., Google Docs)**

**Key Features**:
- Real-time document editing, version history, and user presence.

**Applied Concepts**:
- **WebSockets**: Sync edits across users in real time.
- **Operational Transforms**: Resolve edit conflicts algorithmically.
- **Caching**: Cache frequently accessed documents.
- **Async Processing**: Save versions to the database in the background.
- **Data Replication**: Sync documents across regions for low-latency access.
- **Rate Limiting**: Prevent too many API calls from a single user.

---

### **Key Takeaways**

- **Latency-Sensitive Apps (e.g., real-time chat)**: Prioritize caching, compression, and
WebSockets.
- **High Traffic Apps (e.g., social media)**: Use horizontal scaling, sharding, and CDNs.
- **Data-Heavy Apps (e.g., streaming)**: Leverage object storage, async processing, and CDNs.
- **Transactional Apps (e.g., fintech)**: Focus on redundancy, data replication, and rate limiting.

By mapping concepts to the app’s **core requirements** (e.g., real-time updates, scalability, or
security), you can design systems that are both efficient and resilient. Always start with the
problem, then choose the tools!
———————————————
Core system design concepts:
By understanding these problems, you’ll know **when and why** to apply each concept, rather
than memorizing solutions.

### **1. Vertical Scaling First, Then Horizontal Scaling**

**Problem**:
Your system is underprovisioned (e.g., a single server can’t handle traffic), but you don’t want to
overcomplicate things early.
**Example**:
A new e-commerce app starts with 1,000 daily users. A single server works fine, but as traffic
grows to 10,000 users, the CPU/RAM maxes out, causing slowdowns.
**Why Vertical First?**
It’s simpler and cheaper to upgrade a single server’s resources than to redesign the system for
horizontal scaling.
- **Tools**:
- **Vertical**: Spring Boot embedded server (Tomcat/Netty) with JVM heap tuning (`-Xmx`
flags).
- **Horizontal**: Spring Cloud, Kubernetes, Docker.

---

### **2. Autoscaling for Traffic Spikes**

**Problem**:
Sudden, unpredictable traffic bursts (e.g., a viral post or Black Friday sale) overwhelm fixed
server capacity.
**Example**:
A news website crashes during a breaking news event because servers can’t handle 10x the
usual traffic.
**Solution**:
Autoscaling adds servers during spikes and removes them when traffic drops.
- **Tools**: Kubernetes Horizontal Pod Autoscaler (HPA) + Spring Boot Actuator (metrics).
---

### **3. Load Balancer for High Availability**

**Problem**:
A single server is a bottleneck and a single point of failure (SPOF).
**Example**:
If your payment service runs on one server and it crashes, all transactions fail.
**Solution**:
A load balancer distributes traffic across multiple servers, ensuring no single server becomes a
SPOF.
- **Tools**: Netflix Ribbon (client-side LB), Spring Cloud Gateway, NGINX, or Kubernetes
Ingress.
---

### **4. Cache for Read-Heavy Systems**

**Problem**:
Repeatedly fetching the same data (e.g., product details, user profiles) overloads the database,
slowing response times.
**Example**:
Instagram’s homepage loads slowly because millions of users refresh feeds simultaneously,
hitting the database repeatedly.
**Solution**:
Cache frequently accessed data in-memory (Redis) to reduce database calls.
- **Tools**:
- **Spring Cache** with `@Cacheable`.
- **Redis** (via Spring Data Redis).
- **Caffeine** (in-memory cache).

---

### **5. Document System Requirements**

**Problem**:
Ambiguity in requirements leads to wasted effort (e.g., building for 1M users when only 10K are
needed).
**Example**:
A team builds a video streaming app optimized for 4K resolution but later learns users mostly
watch on mobile with limited bandwidth.
**Solution**:
Document requirements (e.g., target users, latency thresholds) to align the design with actual
needs.
- **Tools**: Swagger/SpringDoc (API documentation), Jira, Confluence.

---

### **6. CDN for Static Asset Latency**

**Problem**:
Users in distant regions experience slow load times for static files (images, videos, CSS/JS).
**Example**:
A user in Australia waits 5 seconds for images hosted on a US server.
**Solution**:
A CDN caches static assets in edge servers closer to users, reducing latency.
- **Tools**: AWS CloudFront, Cloudflare (configured via Spring Boot properties).

---

### **7. Database Indexes for Query Performance**

**Problem**:
Slow queries due to full table scans (e.g., searching for a user by email in a table with 100M
rows).
**Example**:
A user search on LinkedIn takes 10 seconds without an index.
**Solution**:
Indexes create a “quick lookup” structure (like a book’s index) to speed up searches.
- **Tools**:
- **Spring Data JPA** with Hibernate (`@Index` annotations).
- Liquibase/Flyway (schema migration).

---

### **8. Database Replication for Read Scaling**

**Problem**:
A single database can’t handle high read traffic (e.g., analytics dashboards or reporting tools).
**Example**:
A social media app’s database crashes when thousands of users generate reports
simultaneously.
**Solution**:
Read replicas distribute read queries across multiple copies of the database.
- **Tools**:
- **Spring Data JPA** with multiple data sources (primary + replica).
- PostgreSQL/MySQL read replicas.

---

### **9. Database Sharding for Write Scaling**

**Problem**:
A single database hits write limits (e.g., Twitter needing to handle 500M tweets/day).
**Example**:
A single database can only handle 10K writes/sec, but your app needs 100K writes/sec.
**Solution**:
Sharding splits data into smaller chunks (shards) stored on separate servers, spreading the
write load.
- **Tools**: Apache ShardingSphere, Spring Data JPA (custom sharding logic).
---

### **10. Clarify Assumptions First**

**Problem**:
Building a solution based on incorrect assumptions (e.g., assuming users are okay with
eventual consistency).
**Example**:
A team designs a banking app with eventual consistency, not realizing transactions require
strong consistency.
**Solution**:
Ask questions like, “Do we need strong or eventual consistency?” before choosing tools.

---

### **11. CDN for Global Data Distribution**

**Problem**:
Centralized data storage causes high latency for global users.
**Example**:
A user in Japan experiences lag when accessing data stored in a European database.
**Solution**:
CDNs (or geo-replicated databases) replicate data across regions for low-latency access.
- **Tools**: AWS CloudFront, Spring Boot’s resource handling (`ResourceHttpRequestHandler`).
---

### **12. Object Storage for Complex Data**

**Problem**:
Storing large files (videos, images) in a relational database bloats it and slows queries.
**Example**:
Storing 4K videos in PostgreSQL makes backups slow and expensive.
**Solution**:
Object storage (AWS S3) is optimized for large files, scalability, and cost efficiency.
- **Tools**: AWS S3 SDK, Spring Content (for file management).

---

### **13. Rate Limiting for DoS Prevention**

**Problem**:
Malicious bots or users flood your API with requests, causing downtime.
**Example**:
A login endpoint gets 10,000 requests/sec from a botnet, crashing the server.
**Solution**:
Rate limiting blocks excessive requests (e.g., 100 requests/minute per user).
- **Tools**:
- Spring Cloud Gateway (built-in rate limiting).
- Bucket4j (token bucket algorithm).

---

### **14. Redundancy and Isolation for SPOF Removal**

**Problem**:
A single failed component (server, database, network) brings down the entire system.
**Example**:
A cloud provider’s data center outage takes your app offline because you relied on one region.
**Solution**:
Deploy redundant components across zones/regions and isolate failures.
- **Tools**: Kubernetes (pod replicas), Spring Boot Actuator (health checks).

---

### **15. Non-Functional Requirements (NFRs)**

**Problem**:
Ignoring NFRs (e.g., latency, scalability) leads to poor user experience.
**Example**:
An app works functionally but crashes under load or takes 10 seconds to load a page.
**Solution**:
Define NFRs upfront (e.g., “99.9% uptime” or “<2s response time”).
- **Tools**: Micrometer (metrics), Prometheus/Grafana (monitoring).

---

### **16. Data Replication for Fault Tolerance**

**Problem**:
Data loss due to hardware failure or disasters (e.g., disk corruption, fire).
**Example**:
A hospital’s patient records are lost after a server crash.
**Solution**:
Replicate data to multiple locations so backups are always available.
- **Tools**: Cassandra (AP system), Spring Data Cassandra.

---

### **17. Async Processing for Long Tasks**

**Problem**:
Blocking the main thread with slow tasks (e.g., video transcoding) makes the app unresponsive.
**Example**:
A user uploads a video, and the app freezes until processing completes.
**Solution**:
Offload slow tasks to background workers, freeing the main thread for critical operations.
- **Tools**:
- Spring `@Async` + `ThreadPoolTaskExecutor`.
- RabbitMQ (Spring AMQP) / Kafka (Spring Kafka).

---

### **18. Event-Driven Architecture for Loose Coupling**

**Problem**:
Tightly coupled services (e.g., Payment service calling Inventory directly) cause cascading
failures.
**Example**:
If the Inventory service crashes, the Payment service also fails.
**Solution**:
Use message queues (Kafka) to decouple services—Inventory listens for events instead of
direct calls.
- **Tools**: Spring Cloud Stream (Kafka/RabbitMQ bindings).

---

### **19. NoSQL for Unstructured Data**

**Problem**:
Relational databases force rigid schemas, making it hard to store dynamic data (e.g., JSON
logs, sensor data).
**Example**:
Storing IoT device data (varying fields per device) in PostgreSQL requires constant schema
changes.
**Solution**:
NoSQL databases (MongoDB) allow flexible schemas and scale horizontally.
- **Tools**: Spring Data MongoDB / Spring Data Cassandra.

---

### **20. Continuous Feedback During Design**

**Problem**:
Late-stage design flaws due to lack of stakeholder input.
**Example**:
A team builds a feature users don’t need because they didn’t validate assumptions early.
**Solution**:
Regularly share designs with stakeholders to catch issues early.
- **Tools**: Spring Boot Actuator (metrics), Swagger UI (API testing).

---

### **21. Compression and Pagination for Large Data**

**Problem**:
Large API responses (e.g., 10MB JSON) slow down mobile users with poor networks.
**Example**:
A user on a 3G network waits 30 seconds to load a product catalog.
**Solution**:
Compress responses (GZIP) and paginate results (e.g., 100 items/page).
- **Tools**:
- Spring Web (GZIP compression via `server.compression.enabled=true`).
- Spring Data `Pageable` (pagination).

---

### **22. CI/CD for Automated Deployments**

**Problem**:
Manual deployments cause errors and slow releases.
**Example**:
A developer forgets to run tests, deploying buggy code that breaks production.
**Solution**:
CI/CD automates testing and deployment, reducing human error.
- **Tools**: Jenkins, GitHub Actions, GitLab CI (integrated with Maven/Gradle).

---

### **23. Microservices for Independent Deployments**

**Problem**:
Monolithic apps are hard to update, scale, or debug (e.g., one bug crashes the entire app).
**Example**:
Adding a new feature to a monolith requires redeploying the entire codebase, risking downtime.
**Solution**:
Microservices let teams deploy features independently (e.g., update Payments without touching
Orders).
- **Tools**:
- Spring Cloud (Eureka, Config Server, Feign).
- Docker, Kubernetes (orchestration).

---