GDPR and IT Systems — Technical Preparation for the Regulation

Everyone wants microservices. Few know how to get there from an existing monolith without burning down production. We share experiences from decomposing three enterprise monoliths — what worked, what didn’t, and why the Strangler Fig pattern is your best friend.

When (not) to do microservices¶

Martin Fowler says it clearly: “Don’t start with microservices.” If you don’t have problems with scaling, deployment frequency, or team autonomy, microservices add complexity without benefit.

Microservices make sense when:

• You have more than 3 development teams working on one monolith
• Deployment of one feature blocks the release of the entire application
• Different parts of the system need different scaling (checkout vs. product catalog)
• You want to use different technologies for different domains (Python for ML, Go for API)

Strangler Fig Pattern¶

Named after the fig tree that grows around a tree and gradually replaces it. Principle: you build new features as microservices, gradually migrate old ones. The monolith and microservices run in parallel.

# Phase 1: API Gateway routes everything to monolith
/api/users    → monolith
/api/orders   → monolith
/api/products → monolith
/api/payments → monolith

# Phase 2: New payment service, rest on monolith
/api/users    → monolith
/api/orders   → monolith
/api/products → monolith
/api/payments → payment-service (new microservice)

# Phase 3: Gradual migration
/api/users    → user-service
/api/orders   → order-service
/api/products → monolith (for now)
/api/payments → payment-service

Key: never do a big bang rewrite. Each migration is a small, reversible step. If the new service doesn’t work, you switch routing back to the monolith.

Domain-Driven Design — where to cut¶

Most common mistake: cutting microservices by technical layers (UI service, business logic service, data service). The correct approach is to cut by business domains (bounded contexts).

• Order context — order creation, order status, history
• Payment context — payment gateway, refunds, invoicing
• Inventory context — stock levels, reservations, reorder
• User context — registration, authentication, profile, preferences

Each bounded context has its own database. No table sharing between services. This is the most important rule and the hardest to follow.

API Gateway¶

Clients shouldn’t communicate with dozens of microservices directly. API Gateway is a single entry point:

• Kong — open-source, Lua plugins, high performance (nginx-based)
• Netflix Zuul — Java, integrated with Spring Cloud ecosystem
• AWS API Gateway — managed, integrated with Lambda
• Traefik — native Docker/Kubernetes integration, automatic service discovery

API Gateway provides: routing, rate limiting, authentication, request/response transformation, aggregation (BFF — Backend for Frontend pattern).

Distributed Transactions — Saga Pattern¶

In a monolith, you have ACID transactions. In microservices, you don’t — each service has its own database. The Saga pattern solves distributed transactions as a sequence of local transactions with compensating actions:

Saga: Order Creation
1. Order Service    → Create order (PENDING)
2. Payment Service  → Authorize payment
3. Inventory Service → Reserve goods
4. Order Service    → Confirm order (CONFIRMED)

Compensation (if step 3 fails):
3c. Inventory Service → (skip — failed)
2c. Payment Service  → Cancel payment authorization
1c. Order Service    → Cancel order (CANCELLED)

Implementation: choreography (events via message broker — simpler, decentralized) or orchestration (central saga orchestrator — more complex, better visibility).

Communication Between Services¶

Two basic approaches:

• Synchronous (REST/gRPC) — simpler, but creates temporal coupling. If downstream service is unavailable, caller fails.
• Asynchronous (events) — Kafka, RabbitMQ. Services are decoupled, but eventual consistency is harder to debug.

Rule: commands synchronously, events asynchronously. “Create order” is a REST call. “Order was created” is an event on a Kafka topic.

Observability — you must see what’s happening¶

A distributed system without observability is a nightmare. Three pillars:

• Logging — centralized logs with correlation ID (ELK Stack, Fluentd)
• Metrics — Prometheus + Grafana, RED metrics (Rate, Errors, Duration)
• Tracing — Jaeger, Zipkin for visualizing request flow across services

Without distributed tracing, you’ll spend hours finding which of 15 services caused a timeout. With Jaeger, you see it in 10 seconds.

Database Decomposition¶

The hardest part of migration. A monolith typically has one large database with foreign keys between tables. Process:

• Step 1: Separate tables logically (schema per bounded context)
• Step 2: Replace JOINs between contexts with API calls
• Step 3: Physically separate databases
• Step 4: Implement event-driven synchronization where services need data from another context

Microservices are a marathon, not a sprint¶

Monolith decomposition is a process that takes months to years. The Strangler Fig pattern ensures production runs throughout. Start with one service — ideally one with the clearest domain boundary and biggest deployment pain. Learn microservices operations on it (monitoring, deployment, debugging) and then continue with others.