Suggest an editImprove this articleRefine the answer for “What anti-patterns do you know when working with microservices?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)Microservice architecture has a number of typical anti-patterns: a shared database for all services, excessive coupling (chatty communication), shared code, a "monolith made of microservices" (distributed monolith), no DevOps approach, premature splitting, and missing idempotency. **Key point:** microservices only pay off when each service is isolated, independent, and managed through an automated DevOps environment.Shown above the full answer for quick recall.Answer (EN)ImageMicroservice architecture has a number of typical anti-patterns: mistakes that make the system lose its advantages and turn into chaos. Below are the key ones: ### 1. **A shared database for all services** Services work directly with a single database: isolation and the "bounded context" are violated. Result: dependency between schemas, no independent releases, the whole system goes down if the database fails. **Correct approach:** each service owns its own database and talks to others only through APIs or events. ### 2. **Excessive coupling (chatty communication)** Services constantly poke each other with dozens of REST requests. Result: high latency, network failures, lost performance. **Correct approach:** minimize inter-service calls, use asynchronous messaging and an event-driven approach. ### 3. **Shared code or a library for "all" services** Shared utilities start dragging dependencies along and get in the way of independent development. **Better:** duplicate a small amount of code rather than tie services together with a shared business-logic library. ### 4. **A "monolith made of microservices" (distributed monolith)** Formally there are many services, but they are tightly dependent on each other and must be updated together. In essence it is still the same monolith, just spread over the network. **Correct approach:** design independent context boundaries, ensure loose coupling, and enable autonomous releases. ### 5. **No centralized DevOps approach** Each service is deployed manually, without CI/CD or monitoring. Result: chaos in versions, failures during updates. **Solution:** containerization (Docker) + an orchestrator (Kubernetes) + release automation. ### 6. **Premature splitting** Splitting into dozens of microservices without clear business boundaries. The result is a complex, fragile system with a pile of network dependencies. **Better:** start with a modular monolith and split out services gradually. ### 7. **No idempotency or reliable communication** Repeated messages create duplicates, and network failures cause data loss. **Needed:** design idempotent operations and use message brokers with delivery confirmation. **Summary:** > The main anti-patterns are a loss of service autonomy, excessive coupling, and weak infrastructure. > Microservices only pay off when each of them is **isolated, independent, and managed through an automated DevOps environment.**For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.