Careeroza
Choosing the Right Pattern
Problem to Pattern Cheat Sheet
| Problem | Pattern | Where covered |
|---|---|---|
| Clients should not know every service address | API Gateway | Medium level |
| Services find each other dynamically | Service discovery (Eureka / Kubernetes DNS) | Medium level |
| A slow dependency takes everything down | Circuit breaker, timeouts, bulkhead | Medium level |
| Business transaction across services | Saga (choreography / orchestration) | This level |
| Database change + event must both happen | Transactional outbox | This level |
| Duplicate messages and retries | Idempotent consumer, idempotency key | This level |
| Screen needs data from many services | API composition, BFF | This module |
| Complex or heavy queries across services | CQRS read model | This module |
| Migrating a legacy monolith | Strangler fig + anti-corruption layer | This module |
| Cross-cutting concerns (TLS, retries) in every service | Sidecar / service mesh | Security module |
Common Anti-Patterns
| Anti-pattern | Symptom | Fix |
|---|---|---|
| Distributed monolith | Every release needs 5 services deployed together | Redraw boundaries around business capabilities; async events |
| Shared database | payment-service reads order tables directly | Database per service, data via API or events |
| Chatty services | One page = 40 synchronous calls | Batch endpoints, composition, CQRS read model |
| Nano-services | A service per table or per function | Merge into one service per bounded context |
| No observability | "It works on my machine" across 15 services | Tracing, metrics, structured logs from day one |
Tip: Patterns have costs. Start with the simplest thing (a modular monolith, synchronous calls) and add a pattern when a real problem appears. Interviewers like candidates who can say when not to use a pattern.
Exercise
Exercise: ShopEase wants an admin page: "top 10 products by revenue in the last 7 days, with category name and current stock". Data is in order-service (order items), product-service (category) and inventory-service (stock). Which pattern would you use and why?
Show answer
Use a CQRS read model (an analytics/reporting projection), not live API composition.
- Composition would need ALL order items of 7 days from order-service, then
product and stock for each product: slow, heavy, and repeated on every page load.
- Instead, a "product-sales-view" service listens to OrderPlaced / OrderCancelled,
ProductUpdated and StockChanged events and keeps a table:
product_id | name | category | revenue_7d | stock
- The admin page runs one indexed query: ORDER BY revenue_7d DESC LIMIT 10.
- Trade-off: data is a few seconds behind, which is fine for a dashboard.