.
NET DESIGN
QUESTIONS
For Interviews & Development
Design questions that come up in interviews
and during real system development.
+ Repost to help others Swipe >
Q1: Monolith vs. Microservice
THE ANSWER
Don't break a monolith just because it's trendy. The
right move is when multiple teams need autonomy.
DETAILS
• Teams need development/deployment autonomy
• System has clear bounded contexts (Orders, Inventory)
• You need different tech stacks per component
// WARNING
■■ Be ready for: Distributed complexity, network latency, and
operational overhead.
+ Repost to help others Swipe >
Q2: Sync vs. Async Communication?
THE ANSWER
Use both strategically based on the need for
immediacy vs. decoupling.
DETAILS
• Synchronous (HTTP/gRPC): For immediate responses &
real-time queries
• Asynchronous (Messaging): For decoupled, event-driven
workflows
// KEY INSIGHT
■ Messaging (Service Bus, RabbitMQ) increases resilience by
preventing cascading failures.
+ Repost to help others Swipe >
Q3: #1 Rule for Data in Microservices?
THE ANSWER
Database Per Service Principle. Each service owns
its private database schema.
DETAILS
• Never directly query another service's database
• Share data via published events or APIs only
• Enables true loose coupling and autonomy
// THE GOAL
■ Enables true loose coupling and service autonomy.
+ Repost to help others Swipe >
Q4: Handling Data Consistency?
THE ANSWER
Embrace Eventual Consistency with the Saga Pattern
for transactions spanning services.
DETAILS
• Saga orchestrates steps: Flight -> Hotel -> Payment
• If one fails, saga triggers compensation (e.g., Undo
Flight)
// CRITICAL
■ Use CorrelationId to trace the entire transaction across all
services.
+ Repost to help others Swipe >
Q5: Handling Service Failures?
THE ANSWER
Implement the Resilience Pipeline with Polly to keep
the system responsive.
DETAILS
• Circuit Breaker: Stops calling failed services
• Retry with Backoff: Handles transient failures
• Fallback: Provides degraded but functional experience
• Timeout: Prevents indefinite waiting
// RESILIENCE
■ Don't let one failed service take down the whole system.
+ Repost to help others Swipe >
Q7: Debugging Distributed Systems?
THE ANSWER
You need the Three Pillars of Observability to see
what is happening.
DETAILS
• Distributed Tracing: Follow requests end-to-end
(OpenTelemetry)
• Centralized Logging: Aggregate logs in one place
• Metrics: Monitor dashboards and readiness
// WARNING
■■ Without this, you're flying blind in production.
+ Repost to help others Swipe >
Q8: Are K8s & Containers Mandatory?
THE ANSWER
Containers are essential; Kubernetes is the
production standard for non-trivial systems.
DETAILS
• Docker: Provides consistent runtime (dev -> prod)
• Kubernetes: Manages deployment, scaling, discovery
• Simple systems might wait, but growing ones need it
// STANDARD
■ Docker is the unit of deployment; K8s is the orchestrator.
+ Repost to help others Swipe >
Q9: Ultimate Deployment Goal?
THE ANSWER
Independent Deployability. You should be able to
deploy one service without asking others.
DETAILS
• Deploy without coordinating with other teams
• Scale services independently based on load
• Roll back a single service safely
// REQUIRES
■■ Strong contracts, API versioning, and service-specific
CI/CD pipelines.
+ Repost to help others Swipe >
Q10: The Biggest Trade-off?
THE ANSWER
You exchange code complexity for operational
complexity.
DETAILS
• Gain: Team autonomy, flexibility, independent scaling
• Master: Distributed debugging, network reliability,
orchestration
// VERDICT
■■ Powerful for complex systems, but catastrophic over-
engineering for simple apps.
+ Repost to help others Swipe >