Key Building Blocks for Microservice Architecture: Config, Registry, API Gateway & More

Overview

Microservice systems require a set of infrastructure components that provide configuration, discovery, routing, security, asynchronous communication, front‑end optimisation, fault tolerance and load distribution. The following sections describe each component, the problem it solves, and typical implementation details.

Configuration Management

Each service instance may run multiple copies, each needing the same configuration (database URLs, feature flags, etc.). A centralized configuration manager stores these settings in a versioned key‑value store (e.g., Consul KV, Spring Cloud Config, etc.). Services fetch their configuration at startup and can refresh it on demand via a REST endpoint or a watch mechanism, ensuring consistent behaviour across all instances.

Service Registry (Discovery)

Network addresses of service instances change due to scaling, failure recovery or maintenance. A service registry abstracts these mutable addresses behind stable logical names. Each instance registers itself with a unique ID, host/port, and health status, typically via a heartbeat (e.g., every 30 s). Clients query the registry to obtain the current list of healthy instances and perform client‑side load balancing. Popular implementations include Eureka, Consul, and Zookeeper.

API Gateway

The gateway provides a single external entry point for all services. It aggregates the APIs of downstream services, performs request routing based on path or header rules, and terminates TLS. Because it sits at the edge, it is also the natural place to enforce cross‑cutting concerns such as authentication, rate limiting, request/response transformation, and logging. Common solutions are Kong, Spring Cloud Gateway, and NGINX.

Authentication & Authorization Service

Identity verification (Authentication) and permission checks (Authorization) are centralised to avoid inconsistent security states. The gateway typically initiates authentication by validating a token (JWT, OAuth2) and forwards the user’s identity to downstream services. Authorization rules—often expressed as role‑based or attribute‑based policies—are stored centrally (e.g., in an OAuth server or a policy engine like OPA) and consulted by services when needed.

Message Broker (Event Bus)

To decouple services that need to react to business events, a message broker provides publish/subscribe semantics. Producers publish events (e.g., order.created) to a topic or queue; consumers subscribe and process them asynchronously. This pattern eliminates tight coupling, improves scalability, and enables real‑time notifications. Typical brokers are RabbitMQ, Apache Kafka, and Pulsar.

Backend‑for‑Frontend (BFF)

A BFF layer sits between the API gateway and backend services, aggregating multiple service calls into a single response tailored to a specific client type (web, mobile, etc.). It reduces round‑trip latency, hides internal service topology, and allows front‑end teams to evolve their contracts without impacting backend services. Implementation can be a lightweight Node.js/Express service or a Spring Boot application.

Circuit Breaker

Remote calls may fail or become unresponsive, causing cascading failures. A circuit breaker monitors call latency and error rates; when a configurable threshold (e.g., 50 % failures over 10 seconds) is exceeded, the breaker opens and short‑circuits further calls, optionally returning a fallback response. After a cool‑down period, it transitions to a half‑open state to test the downstream service again. Libraries such as Netflix Hystrix, Resilience4j, or Spring Cloud CircuitBreaker implement this pattern.

Load Balancing

Two main strategies distribute traffic across service instances:

Client‑side load balancing : The client obtains the list of healthy instances from the service registry and selects one using round‑robin, random, or weighted algorithms (e.g., Ribbon, Spring Cloud LoadBalancer).

Mid‑tier load balancing : A dedicated load‑balancer (e.g., Envoy, HAProxy, cloud LB) or DNS resolves the logical service name to a virtual IP, handling distribution before the request reaches the client.

Centralisation vs. Semi‑Centralisation

When extending the infrastructure, architects must decide which components stay fully centralised (configuration, service registry, message queue) and which can be semi‑centralised (routing, authentication). Over‑centralisation reduces flexibility; a balanced approach allows teams to evolve independently while preserving shared contracts.

Summary of Core Components (in request flow order)

Configuration Management : Centralised key‑value store, versioned, supports hot reload.

API Gateway : Single external entry point, request routing, TLS termination, initiates authentication.

Service Registry : Dynamic registration and discovery of service instances.

Authentication Service : Validates identity tokens and provides user context.

Backend‑for‑Frontend (BFF) : Aggregates and transforms multiple service calls per client type.

Message Broker : Publishes events, enables asynchronous processing and fan‑out.

Circuit Breaker : Monitors remote call health, opens on failure thresholds, supplies fallbacks.

Load Balancer : Distributes traffic to avoid overload, supports client‑side and mid‑tier modes.

Each module should be evaluated against project size, team structure, and performance requirements. Proper composition of these building blocks yields a resilient, scalable, and maintainable microservice architecture.