microservices_architect

Decompose a monolith by running event storming workshops to identify bounded contexts via domain-driven design, then apply the Strangler Fig pattern to gradually replace monolith functionality. Verify each new service satisfies the independent deployability principle before proceeding.

Use synchronous REST or gRPC for request-response interactions within aggregates, and asynchronous messaging via Kafka or RabbitMQ for cross-aggregate operations. Avoid synchronous calls for long-running operations to prevent cascading latency and failures.

No, sharing databases between services is an anti-pattern that creates tight coupling and distributed monoliths. Each service should own its database schema, using event sourcing or CQRS when cross-service data consistency is required.

Prevent cascading failures by implementing circuit breakers, retries with backoff, timeouts, and bulkhead isolation for every external call. Combine these with health checks, readiness probes, and distributed tracing to detect and contain failures early.

Avoid microservices when a monolith-first approach suffices, such as early-stage products with unclear domain boundaries or small teams. Distributed systems add operational complexity in observability, deployment, and data consistency that must be justified by scale needs.