Monolithic vs Microservices Architecture: Advantages, Disadvantages, Gateways, Service Registration, and Configuration Centers

1. Monolithic Architecture

1.1 What is a monolithic structure?

In the early days of web development most applications were packaged as a single WAR and deployed to one web container, e.g., an online shop where order processing, inventory, and shipping logic all run in the same JVM.

Such a system is called a monolithic (or "giant‑stone") architecture.

1.2 Advantages of monoliths

Easy development : IDE support, simple debugging.

Easy testing : All functionality runs in one process.

Easy deployment : Deploy a single artifact.

Horizontal scaling : Add identical nodes and load‑balance.

1.3 Disadvantages of monoliths

High maintenance cost : Larger codebase, longer build and test cycles.

Long continuous‑delivery cycles : Any change triggers a full rebuild.

Long onboarding for newcomers .

Technology lock‑in : Hard to upgrade frameworks.

Poor scalability : Vertical scaling becomes expensive.

2. Microservices

2.1 What is a microservice?

A microservice architecture splits business logic into many small, loosely‑coupled distributed components, each responsible for a single capability (e.g., order service, user service).

Key characteristics include independent processes, lightweight communication (HTTP/TCP), and the ability to deploy each service separately.

2.2 Advantages of microservices

System decomposition : Reduces complexity by breaking a huge monolith into manageable services.

Team autonomy : Each service can be owned by a dedicated team that chooses its own technology stack.

Simplified deployment & scalability : Services are deployed independently and can be scaled per‑service.

2.3 Disadvantages of microservices

Service size limits : Over‑splitting can create unnecessary overhead.

Increased coding complexity : Distributed systems require RPC, messaging, and fault‑tolerance handling.

Data management challenges : Distributed transactions and separate databases become harder.

Testing complexity : End‑to‑end tests must spin up multiple services or stubs.

Change propagation : Modifying one service may affect many others.

Network sensitivity : Latency and bandwidth impact inter‑service calls.

2.4 Microservice architecture layers

The typical stack (from outside to inside) includes: Access layer, Gateway layer, Business service layer, Support service layer, Platform service layer, and Infrastructure layer.

3. Microservice Gateway

3.1 What is a service gateway?

A service gateway combines routing and filter functions. It receives external requests, forwards them to backend services, and can perform cross‑cutting concerns such as authentication, rate limiting, logging, and data transformation.

3.2 Why use a gateway?

Centralises common concerns (auth, session, security, logging) so individual services stay lightweight.

Three implementation options for permission checks: Each service implements its own check (redundant code). Extract checks into a shared service (adds dependency and jar size). Implement checks in the gateway filter (preferred).

3.3 Gateway functions

Routing : Directs requests to the appropriate microservice, optionally using service‑registry data.

Load balancing : Distributes traffic based on instance health.

Security authentication : Verifies identity before forwarding.

Logging : Captures request/response data for audit and monitoring.

Data conversion : Normalises client payloads for backend services.

3.4 Open‑source gateway projects

Zuul (Netflix, Java‑based, integrates with Spring Cloud)

Tyk (Go, lightweight, supports quotas, authentication)

Kong (Nginx/OpenResty based, high performance, plugin ecosystem)

Traefik (dynamic configuration, integrates with Docker, Kubernetes, etc.)

Ambassador (Envoy‑based, works well with Istio)

4. Service Registration and Discovery

4.1 Why is registration needed?

In a large microservice cluster, providers and consumers need a dynamic way to locate each other because instances appear and disappear frequently.

4.2 Registration principles

Self‑registration : Each service registers itself on startup.

Third‑party registration : An external manager (e.g., Eureka) polls services and updates the registry.

4.3 Discovery patterns

Client‑side discovery : The consumer queries the registry and calls the provider directly.

Server‑side (proxy) discovery : The consumer talks to an API gateway, which performs the lookup and routing.

4.4 Open‑source registries

Eureka (Netflix, Spring Cloud integration)

Consul (language‑agnostic, agent‑based health checks)

Etcd (distributed KV store, often combined with other tools)

5. Configuration Center

5.1 What is a configuration center?

A centralized system that stores all configuration items for all environments and services, providing a unified API for retrieval and real‑time push of updates.

5.2 Why use one?

Eliminates scattered static files.

Supports environment‑specific values without code changes.

Allows live updates without restarts.

Tracks version history for auditability.

Ensures high availability because many services depend on it.

5.3 Open‑source configuration solutions

Apollo (Ctrip, Java/Go/.NET clients, Spring Boot support)

XDiamond (Alibaba‑inspired, simple KV store)

QConf (Qihoo 360, high‑performance KV with push)

Disconf (widely used in Chinese internet companies)

Conclusion

The article contrasted monolithic and microservice structures, highlighting their pros and cons.

It covered gateway design, service registration/discovery, and distributed configuration management.

Further topics include service frameworks, monitoring, governance, circuit breaking, and degradation strategies.