Anti-patterns in Software Architecture

Common mistakes in distributed software architecture: how to spot them, their real impact, and the strategies to fix them.

What anti-patterns are

An anti-pattern is a recurring solution that seems reasonable at first but causes significant problems in the medium and long term. Unlike a simple mistake, anti-patterns are common traps that experienced teams fall into, often due to time pressure, lack of context, or decisions that were correct at one point but stopped being so.

Recognizing these anti-patterns early lets you avoid costly technical debt and make more informed architectural decisions.

Why anti-patterns arise

Anti-patterns don’t appear out of incompetence. They arise for understandable reasons:

1. Distributed Monolith

Problem

This happens when a system is split into multiple services that depend on each other so tightly that they cannot be deployed, scaled, or evolved independently. In practice, you get the operational complexity of microservices without any of their benefits.

┌──────────┐     ┌──────────┐     ┌──────────┐
│Service A │────►│Service B │────►│Service C │
│          │◄────│          │◄────│          │
└──────────┘     └──────────┘     └──────────┘
     │                │                │
     └────────────────┴────────────────┘
        Mandatory joint deployment
        Shared data models
        Chained synchronous calls

The clearest signs are:

• You need to deploy several services at once for a change to work
• A change to one service’s contract breaks the others
• Services share internal libraries containing business logic
• Integration tests require spinning up the entire system

Impact

• Fragile deployments: A change in one service requires coordinating the deployment of others, eliminating the agility that motivated the split
• Cascading failures: The synchronous dependency between services means one going down drags the others with it
• Complexity without benefit: The team pays the operational cost of multiple services without gaining real independence
• Reduced development velocity: Teams can’t work in parallel because changes block one another

How to detect it

• Ask: can I deploy this service without touching any other? If the answer is frequently “no,” you have a distributed monolith
• Check whether services share database schemas or libraries containing domain logic
• Observe whether releases require coordination across multiple teams for a single functional change
• Measure the coupling score: count how many services get deployed together in each release

Fix

2. Shared Database

Problem

Multiple services read and write directly to the same database, accessing the same tables. This creates invisible coupling: services don’t depend on explicit APIs but on the internal structure of the tables.

┌──────────┐   ┌──────────┐   ┌──────────┐
│Service A │   │Service B │   │Service C │
└────┬─────┘   └────┬─────┘   └────┬─────┘
     │              │              │
     ▼              ▼              ▼
┌──────────────────────────────────────┐
│           Shared Database            │
│                                      │
│  ┌─────────┐ ┌─────────┐ ┌────────┐ │
│  │ Table X │ │ Table Y │ │ Table Z│ │
│  └─────────┘ └─────────┘ └────────┘ │
│                                      │
│  Everyone reads and writes to all    │
└──────────────────────────────────────┘

The clearest signs are:

• Several services run direct queries against the same tables
• A schema change requires modifying multiple services
• There’s no clear “owner” for each table or dataset
• Database migrations are high-risk events

Impact

• Hidden coupling: Services appear independent but are tied together by the database structure. An ALTER TABLE can break services you didn’t even know were using that table
• Limited scalability: You can’t scale the database independently per service
• Dangerous migrations: Any schema change is a risk because you don’t know who depends on what
• Impossible to evolve: Each service stays tied to the technology and structure of the shared database

How to detect it

• Check whether more than one service has connection strings to the same database
• Look for queries that access tables “belonging” to another functional domain
• Ask: who owns this table? If the answer is “several services,” you have this anti-pattern
• Run a dependency analysis: map which services access which tables

Fix

3. God Service

Problem

A single service concentrates too many responsibilities and becomes the central point through which almost all of the system’s logic flows. It usually starts as a legitimate service that keeps accumulating features because “it’s easier to add it here.”

                    ┌─────────────────────┐
                    │    God Service       │
                    │                     │
                    │  • Authentication   │
                    │  • Users            │
                    │  • Orders           │
                    │  • Payments         │
                    │  • Notifications    │
                    │  • Reports          │
                    │  • Inventory        │
                    └──────────┬──────────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        ┌──────────┐   ┌──────────┐    ┌──────────┐
        │Service X │   │Service Y │    │Service Z │
        │(simple)  │   │(simple)  │    │(simple)  │
        └──────────┘   └──────────┘    └──────────┘

        Everyone depends on the God Service

The clearest signs are:

• One service has significantly more endpoints than the others
• Most functional changes require modifying that service
• The service has multiple unrelated responsibilities
• The team maintaining it is a constant bottleneck

Impact

• Development bottleneck: Every team needs to modify the same service
• Single point of failure: If the God Service goes down, a large part of the system stops working
• Uneven scalability: You can’t scale payments alone if it’s bundled with reports
• Growing complexity: The service becomes hard to understand, test, and maintain
• Risky deployments: Every deployment touches many features

How to detect it

• Measure lines of code or endpoints per service. If one has 10x more than average, it’s suspicious
• Review the commits: if one service concentrates most changes from multiple teams, it’s probably a God Service
• Ask: can I describe this service’s responsibility in a single sentence? If you need a long list, it has too many responsibilities
• Analyze the dependencies: if most services depend on a single one, it’s a God Service

Fix

4. Chatty Services

Problem

Services communicate with each other using too many fine-grained calls to complete a single operation. Instead of one request that fetches all the needed information, a service makes multiple small calls.

Service A needs to display a user's profile:

  Service A → Users Service:  GET /users/123
  Service A → Users Service:  GET /users/123/preferences
  Service A → Orders Service: GET /orders?user=123
  Service A → Orders Service: GET /orders/456/details
  Service A → Orders Service: GET /orders/789/details
  Service A → Payments Service: GET /payments?user=123
  Service A → Reviews Service:  GET /reviews?user=123

  Total: 7 network calls for a single screen

The clearest signs are:

• A business operation generates more than 3-4 calls between services
• Latency is high even though each individual service responds fast
• Logs show bursts of correlated calls for a single request

Impact

• Accumulated latency: 7 calls of 50ms each add up to 350ms in the best case (sequential)
• Fragility: With 7 calls and 99% availability per service, effective availability drops to ~93%
• Excessive network load: Internal traffic can exceed external traffic
• Debugging difficulty: Tracing an error across multiple calls requires distributed tracing

How to detect it

• Count the inter-service calls generated by a single user request
• Measure end-to-end latency vs. the individual latency of each service
• Check whether services expose very granular endpoints

Fix

5. Anemic Domain Model

Problem

Domain entities are data containers without behavior — they only have getters and setters. All the business logic lives in external services that manipulate these passive entities.

// ❌ Anemic model
class Order {
  id: string;
  status: string;
  lines: OrderLine[];
  total: number;
  // Only getters and setters, no logic
}

class OrderService {
  confirm(order: Order) {
    if (order.status !== 'draft') throw new Error('...');
    if (order.lines.length === 0) throw new Error('...');
    order.status = 'confirmed';
    order.total = this.calculateTotal(order.lines);
    // All the logic is here, not in Order
  }
}

// ✅ Rich model
class Order {
  confirm() {
    if (this.status !== 'draft')
      throw new Error('Only a draft order can be confirmed');
    if (this.lines.length === 0)
      throw new Error('The order must have at least one line');
    this.status = 'confirmed';
    this.total = this.calculateTotal();
    this.recordEvent(new OrderConfirmed(this.id));
  }
}

Impact

• Scattered logic: Business rules get duplicated across multiple services
• Hard to test: Tests need to set up external services to validate simple rules
• Encapsulation violation: Anyone can modify the entity’s state without going through the rules
• Hard to discover: It’s not obvious which operations are valid on an entity

Fix

6. Database Integration

Problem

Services integrate by reading and writing to other services’ tables instead of communicating through APIs or events. It’s a more subtle variant of the shared database.

Service A needs to know whether a user is premium:

  ❌ SELECT type FROM users WHERE id = 123
     (accesses Service B's table directly)

  ✅ GET /api/users/123/subscription
     (queries Service B through its API)

Impact

• Invisible coupling: There’s no explicit contract, only implicit knowledge of the table structure
• Impossible to version: You can’t evolve the schema without breaking the hidden consumers
• No access control: Any service can read or write any data

Fix

Comparative summary

How to prevent anti-patterns

Anti-patterns rarely appear all at once. They accumulate gradually. Some practices that help prevent them:

• Periodic architecture reviews: Regularly assess whether services maintain their independence
• Fitness functions: Define automated metrics that detect coupling (number of dependencies, service size, frequency of joint deployments)
• ADRs (Architecture Decision Records): Document architectural decisions and their rationale
• Clear ownership: Every service, table, and API must have a responsible team
• Razor principle: If you can’t justify why a service is independent, it probably shouldn’t be
• Coupling monitoring: Measure how many services deploy together, how many synchronous calls exist between services, and how many tables are shared

Relationship with other patterns

Anti-patterns are prevented and corrected by applying the right patterns:

Anti-pattern                   Pattern that fixes it
─────────────────────────────────────────────────────
Distributed Monolith    →  DDD (Bounded Contexts)
                        →  Event-Driven Architecture
                        →  ACL Pattern

Shared Database          →  Database per Service
                         →  Outbox Pattern (synchronization)
                         →  Event-Driven Architecture

God Service             →  Microservices Pattern
                        →  DDD (decomposition by domain)
                        →  API Gateway / BFF

Chatty Services         →  BFF Pattern
                        →  API Gateway Pattern
                        →  Event-Driven Architecture

Anemic Model            →  DDD (tactical design)
                        →  Aggregates + Domain Events

Database Integration    →  ACL Pattern
                        →  Outbox Pattern
                        →  Shared Kernel (controlled)

Next steps

Now that you know the most common anti-patterns, dig deeper into the patterns that prevent them: DDD to define clear bounded contexts, Microservices Pattern to decompose correctly, Event-Driven Architecture to decouple services, and BFF Pattern to solve the chatty services problem.