Principles of Product Management: Software Architecture Basics (Monolith vs Microservices, Client‑Server, Database Basics)

Software Architecture Basics (Monolith vs Microservices, Client‑Server, Database Basics)

Software Architecture Basics (Monolith vs Microservices, Client-Server, Database Basics)

What This Is

Software architecture defines how your product’s code, data, and services are structured—impacting scalability, speed, cost, and team velocity. A poor choice can bottleneck growth (e.g., Twitter’s early monolith struggled with scaling, leading to the "Fail Whale"), while the right one enables rapid iteration (e.g., Netflix’s shift to microservices allowed global streaming with 99.99% uptime). As a PM, you don’t need to code, but you must understand trade-offs to align engineering with business goals (e.g., "Should we build this feature as a microservice to enable faster A/B testing?").

Key Terms & Frameworks

• Client-Server Model:
  The standard architecture where clients (e.g., mobile apps, browsers) request data/services from servers (e.g., backend APIs, databases). Example: When you load Instagram, your phone (client) fetches posts from Meta’s servers.

• Monolithic Architecture:
  A single, unified codebase where all features (e.g., user auth, payments, recommendations) run as one deployable unit. Pros: Simple to develop/test. Cons: Hard to scale, slow deployments, tight coupling. Example: Early Airbnb or Shopify.

• Microservices Architecture:
  Breaks the product into small, independent services (e.g., "User Service," "Payment Service") that communicate via APIs. Pros: Scalable, fault-isolated, faster deploys. Cons: Complexity, operational overhead. Example: Amazon, Uber, Netflix.

• Service-Oriented Architecture (SOA):
  A precursor to microservices where services are larger and share infrastructure (e.g., a single database). Less granular than microservices.

• Database (DB):
  Stores and retrieves data. Types:

• SQL (Relational): Structured tables with relationships (e.g., PostgreSQL, MySQL). Best for complex queries (e.g., financial transactions).
• NoSQL: Flexible schemas (e.g., MongoDB, DynamoDB). Best for unstructured data (e.g., user profiles, logs).

• Cache: Temporary, fast storage (e.g., Redis) to reduce DB load. Example: Storing trending tweets to avoid querying the main DB repeatedly.

• API (Application Programming Interface):
  A contract between services (e.g., "This endpoint returns user data in JSON format"). Types:

• REST: Standard HTTP-based APIs (e.g., GET /users).
• GraphQL: Clients request only the data they need (e.g., Facebook’s mobile app fetching posts + comments in one call).

• gRPC: High-performance APIs (e.g., Google’s internal services).

• Latency vs. Throughput:

• Latency: Time for a single request (e.g., 200ms to load a page). Goal: Minimize.

• Throughput: Requests handled per second (e.g., 10,000 orders/minute). Goal: Maximize.

• CAP Theorem:
  In distributed systems, you can only guarantee 2 of 3 properties:

• Consistency: All nodes see the same data at the same time.
• Availability: Every request gets a response (even if stale).

• Partition Tolerance: System works despite network failures.
  Example: DynamoDB prioritizes Availability and Partition Tolerance (AP), while PostgreSQL prioritizes Consistency and Availability (CA).

• Event-Driven Architecture:
  Services react to events (e.g., "User signed up") via a message broker (e.g., Kafka, RabbitMQ). Example: Uber’s ride-matching system triggers events like "Driver accepted ride."

• Serverless:
  Cloud providers (AWS Lambda, Google Cloud Functions) run code without managing servers. Pros: Pay-per-use, auto-scaling. Cons: Cold starts, vendor lock-in. Example: Processing Stripe webhooks for payments.

• Tech Debt:
  The cost of future rework caused by choosing an easy/short-term solution now. Example: Hardcoding a feature instead of building a configurable system.

• Conway’s Law:
  "Organizations design systems that mirror their communication structures." Example: If your teams are siloed (e.g., "Mobile Team" vs. "Backend Team"), your architecture will likely be monolithic.

Step-by-Step / Process Flow

How to evaluate architecture choices for a product feature:

1. Map the Feature to Business Goals
2. Ask: "Does this feature need to scale independently? Is it core to revenue?"

3. Example: For a fintech app, payments are core (→ microservice), while user profiles may not be (→ monolith).

4. Assess Current Architecture

5. Ask engineering: "What’s our current system’s bottleneck? Latency? Throughput? Deployment speed?"

6. Use tools like:

   
   
   • New Relic/Datadog: Monitor latency/errors.
   • AWS Well-Architected Tool: Audit cloud setup.

7. Evaluate Trade-offs
   | Factor | Monolith | Microservices |
   |----------------------|----------------------------|----------------------------------|
   | Speed to Market | Faster (1 codebase) | Slower (setup overhead) |
   | Scalability | Hard (scale entire app) | Easy (scale only needed services)|
   | Team Size | Small teams | Large teams (DevOps needed) |
   | Fault Isolation | One bug crashes everything | Bugs are isolated |
   | Cost | Lower (fewer servers) | Higher (more servers, monitoring)|

8. Prototype and Measure

9. For a new feature, build a spike (time-boxed prototype) to test performance.

10. Example: If adding a "Recommendations" feature, measure:

    
    
    • Latency: Time to generate recommendations.
    • Throughput: Requests/second during peak traffic.

11. Align with Engineering and Business

12. Present findings to stakeholders using the DARCI Model (Decision-maker, Accountable, Responsible, Consulted, Informed).

13. Example: "We recommend a microservice for the new AI chatbot because it needs to scale independently and handle 10K+ concurrent users."

14. Plan for Migration (If Needed)

15. Use the Strangler Pattern: Gradually replace parts of a monolith with microservices (e.g., extract "Payments" first, then "User Auth").
16. Example: Amazon migrated from a monolith to microservices over 10 years.

Common Mistakes

• Mistake: Assuming microservices are always better.
  Correction: Microservices add complexity. Use them only if:
• The feature needs independent scaling (e.g., video encoding).
• The team is large enough to handle DevOps (e.g., 50+ engineers).

• The business can afford higher cloud costs.

• Mistake: Ignoring database choice until late.
  Correction: Pick early based on data structure:

• SQL: Transactions (e.g., banking), complex queries.

• NoSQL: High write volume (e.g., logs), flexible schemas.

• Mistake: Not defining API contracts upfront.
  Correction: Use OpenAPI/Swagger to document endpoints before coding. Example: "The /orders endpoint must return order_id, status, and timestamp."

• Mistake: Over-optimizing for latency when throughput is the bottleneck.
  Correction: Measure first! Example: If your e-commerce site handles 100 orders/second but pages load in 500ms, focus on throughput (e.g., caching, DB sharding).

• Mistake: Treating tech debt as "engineering’s problem." Correction: Track it like a feature. Use the Tech Debt Quadrant (from Martin Fowler):

• Reckless/Deliberate: "We’ll fix it later" (bad).
• Prudent/Deliberate: "We’ll refactor after launch" (good).

PM Interview / Practical Insights

1. Tricky Question: "Should we migrate from a monolith to microservices?"
2. Answer: "It depends. What’s the business goal? If we’re struggling with slow deploys or scaling, yes. If we’re a small team with a simple product, no—microservices add overhead."

3. Follow-up: "How would you measure success?" → "Reduced deployment time by 50% and improved uptime from 99.5% to 99.9%."

4. Stakeholder Trap: Engineers say, "We need to rewrite the monolith in Go for performance."

5. PM Response: "What’s the ROI? Let’s quantify the performance gain (e.g., 20% faster) vs. the 6-month delay in feature development. Can we optimize the current system first?"

6. Interview Probe: "How would you design the architecture for a new social media app?"

7. Framework to Use:

   
   
   1. Start with a monolith (fast to build).
   2. Identify core services (e.g., "Posts," "Messaging") that may need microservices later.
   3. Use caching (Redis) for feeds.
   4. Pick NoSQL (e.g., MongoDB) for user-generated content (flexible schema).
   5. Plan for event-driven features (e.g., notifications).

8. Distinction: "What’s the difference between a microservice and a module in a monolith?"

9. Answer: A module is a logical separation within a monolith (e.g., "Payment Module"), while a microservice is a physically separate service with its own DB and API.

Quick Check Questions

1. Scenario: Your team wants to add a real-time chat feature to a monolithic e-commerce app. The engineers say it’ll take 3 months to build as a microservice. What do you do?
2. Answer: "Start with a monolith module first (e.g., 1-month MVP), then extract to a microservice if chat becomes a core product (e.g., customer support drives 20% of revenue)."

3. Why: Avoid premature optimization; validate the feature’s value first.

4. Scenario: Your database latency spikes during Black Friday sales. What’s the first thing you check?

5. Answer: "Check if the bottleneck is read-heavy (→ add caching) or write-heavy (→ scale DB or use a message queue)."

6. Why: Latency causes differ; caching won’t help if the DB is overwhelmed by writes.

7. Scenario: A stakeholder asks, "Why can’t we just use a single database for everything?"

8. Answer: "We can, but it creates a single point of failure and makes scaling harder. For example, if the ‘Orders’ table grows to 100M rows, it’ll slow down the ‘User Profiles’ table too."
9. Why: Explain trade-offs in plain business terms (downtime, speed).

Last-Minute Cram Sheet

1. Monolith vs. Microservices: Monolith = fast to build, hard to scale; Microservices = scalable, complex.
2. Client-Server: Client requests, server responds (e.g., mobile app → API).
3. SQL vs. NoSQL: SQL = structured data (transactions); NoSQL = flexible (user profiles).
4. CAP Theorem: Choose 2 of 3: Consistency, Availability, Partition Tolerance.
5. Latency vs. Throughput: Latency = speed of 1 request; Throughput = requests/second.
6. Tech Debt Quadrant: Avoid "reckless/deliberate" debt (e.g., "We’ll fix it later").
7. Strangler Pattern: Gradually replace a monolith with microservices.
8. Event-Driven: Services react to events (e.g., "User signed up" → send email).
9. ⚠️ API Contracts: Define endpoints before coding (use OpenAPI).
10. Conway’s Law: Your architecture mirrors your team structure (silos → monolith).