Microservices vs Monoliths for PMs

Microservices vs Monoliths

Quick Definitions

• Monolith: Like a single restaurant kitchen where everything is made in one place. All features share the same codebase and deploy together. One team can understand the whole system.
• Microservices: Like a food court with specialized vendors. Each feature is a separate service with its own code, database, and deployment. Teams work independently.

Decision Matrix

When to Choose Each

Choose Monolith when:

• Team is <20 engineers or single product team
• Product-market fit is uncertain (needs rapid iteration)
• Domain boundaries are unclear
• Engineering resources are limited

Choose Microservices when:

• You have 50+ engineers across multiple teams
• Different features have vastly different scale needs
• Teams need to deploy independently without coordination
• Regulatory requirements isolate certain data (PCI compliance)

Scenario 1: E-commerce Platform Growth

Product Problem:
Your e-commerce site has grown from 10 to 100 engineers. Checkout team wants to deploy payment fixes but is blocked by marketing team’s homepage redesign. Deployments now take 3 hours and happen only twice a week.

PM Decision:
Extract checkout, inventory, and payment processing into separate microservices. Keep product catalog in the monolith initially.

Trade-offs:

Real Numbers:

• Deployment frequency: 2x/week → 50x/week (across all teams)
• Payment feature velocity: +200% (team autonomy)
• Infrastructure costs: $50K/month → $70K/month
• Median incident duration: 45min → 15min (isolated failures)

Scenario 2: Social Media Startup Decision

Product Problem:
You’re a 15-person startup building a social app. Investors are asking why you’re not using microservices “like Netflix.” Monolith deploys in 10 minutes; everyone understands the codebase.

PM Decision:
Stay with monolith for at least 12 months. Revisit when team hits 40+ engineers or you see specific scaling pain.

Model Answer (Trade-off Sandwich):
“I’d keep the monolith for now. Our deployment takes 10 minutes, which is fine for our size—we ship 20 times a week without coordination overhead. Microservices would require 2 engineers full-time on DevOps, which is 13% of our team. The trade-off is we might need to extract services later, but that’s a 3-month project when we have 50 engineers vs a 6-month distraction now.”

Real Numbers:

• Feature velocity: 8 features/month (monolith) vs 2 features/month (if microservices)
• Infrastructure costs: $5K/month (monolith) vs $15K/month (microservices)
• Engineering time on ops: 5% (monolith) vs 30% (microservices for small team)

Interview Response Frameworks

Framework 1: UPBT

“Users are impacted when bug fixes take 3 days to deploy because of coordination overhead. The product suffers from reduced velocity—teams are shipping 50% less due to deployment conflicts. This hits our competitive position. Technically, I’d recommend extracting the highest-pain services first—likely checkout and inventory. I’d measure success by deployment frequency per team.”

Framework 2: Scale-Based Decision Matrix

Practice Question

Interview Prompt:
“You’re joining a 25-person startup as Head of Product. Engineering wants to move from monolith to microservices because ‘that’s what Netflix does.’ How would you think about this decision?”

Key Points to Cover:

• Netflix has 1000+ engineers; premature optimization is real
• Microservices have operational overhead
• Deployment frequency and team conflicts are better signals than ideology

Model Answer (Trade-off Sandwich):
“I’d start by understanding the current pain. If deploys take 10 minutes and we ship 20x/week without conflicts, I’d recommend staying monolithic. This keeps our 25-person team focused on product features rather than infrastructure. The trade-off is we might refactor in 18 months when we hit 50+ engineers, but that’s a 3-month project then vs 6 months of distraction now. I’d revisit when we see specific signals: deploy time >1 hour, teams blocking each other on releases, or one feature needing 10x the infrastructure of others.”

Quick Reference: Microservices vs Monoliths

30-Second Comparison:
Monolith = one kitchen making everything. Fast to start, slows as you grow. Microservices = food court with specialized vendors. High setup cost, scales with teams.

Decision Heuristic:

• <20 engineers? → Monolith
• 50+ engineers with team conflicts? → Consider extraction
• Uncertain domain? → Monolith
• Deployment conflicts weekly? → Consider extraction

Red Flags (what NOT to say):

• Don’t mention: Kubernetes, Docker, specific frameworks unless asked
• Avoid: “Microservices are always better” or “Monoliths are legacy”
• Never: Choose architecture without discussing team size

Power Phrases:

• “The right architecture depends on team size and organizational structure…”
• “At [X engineers], I’d expect to see [this pain point]…”
• “Conway’s Law tells us our architecture should match how teams work…”
• “I’d know it’s time to switch when [specific metric]…”

Anti-Patterns to Mention:

• Distributed monolith (microservices that all deploy together)
• Premature extraction (microservices before product-market fit)
• Big-bang rewrites (migrate gradually instead)