Microservices
technicalFull Name: Microservices Architecture
Definition
Microservices architecture is a software design approach that structures an application as a collection of small, autonomous services, each running in its own process, communicating over lightweight protocols (typically HTTP/REST or gRPC), and independently deployable. Each microservice is organized around a specific business capability and can be developed, tested, deployed, and scaled independently. In the EUDI Wallet ecosystem, microservices architecture is the standard approach for backend infrastructure, decomposing the complex identity management system into focused services for credential issuance, presentation verification, status management, trust registry operations, and key management -- each optimized for its specific function and scalability requirements.
EUDI Wallet Backend Service Decomposition
A typical EUDI Wallet backend implemented as microservices consists of several independently deployed services. The Credential Issuance Service implements the OpenID4VCI protocol, handling requests from wallet applications to issue new credentials. It validates authorization, retrieves user attributes from authoritative sources, signs credentials using the issuer's key, and returns the formatted credential (in SD-JWT or mDoc format) to the wallet.
The Verification Service processes OpenID4VP requests from relying parties, validating presented credentials against the trust framework. It checks issuer signatures, verifies the credential format, confirms the device binding proof, and validates the credential's revocation status before returning the verified attributes to the requesting relying party.
The Status Service manages credential lifecycle, particularly revocation. When an issuer needs to revoke a credential (due to data changes, fraud, or user request), the Status Service updates the relevant status list. Verifiers query this service to confirm that credentials are still valid. The Status Service must be highly available, as every credential verification may include a status check.
Supporting services include the Trust Registry Service (maintaining the authoritative list of trusted issuers, their public keys, and authorized credential types), the Key Management Service (handling cryptographic operations including key rotation and HSM integration), and infrastructure services for logging, monitoring, rate limiting, and configuration management.
Scalability and Resilience Patterns
The primary benefit of microservices for EUDI Wallet infrastructure is independent scalability. During a national wallet rollout, the issuance service may need to handle millions of credential requests while the verification service has minimal load. With microservices, the issuance service can be scaled to 50 instances while the verification service runs with just a few -- impossible with a monolithic architecture where all components scale together.
Kubernetes horizontal pod autoscaling enables automatic scaling based on metrics like CPU usage, request rate, or queue depth. Each microservice defines its own scaling policies. The Status Service might scale based on query rate, while the Issuance Service scales based on pending credential requests in its queue.
Fault isolation is critical for identity infrastructure. If the Key Management Service experiences a temporary issue, it should not bring down the Verification Service that relies on cached key material. Circuit breaker patterns prevent cascading failures: if a downstream service is unhealthy, the circuit breaker stops sending requests and returns a graceful degradation response, allowing the overall system to continue operating in a reduced capacity.
Bulkhead patterns further isolate failures by assigning separate resource pools (thread pools, connection pools) to different service interactions. A slow response from the Trust Registry cannot exhaust the connection pool used for Status Service queries, ensuring that independent service paths remain responsive even when specific paths experience issues.
Inter-Service Communication and Security
Communication between EUDI Wallet microservices must be both efficient and secure. Synchronous communication (HTTP/REST or gRPC) is used for request-response interactions like credential verification, where the calling service needs an immediate answer. Asynchronous communication (message queues like RabbitMQ or Apache Kafka) is used for event-driven interactions like propagating revocation events, where eventual consistency is acceptable.
mTLS (Mutual TLS) is the standard for securing inter-service communication in EUDI Wallet infrastructure. Service mesh technologies like Istio or Linkerd automate mTLS between all services, encrypting all inter-service traffic and providing mutual authentication without requiring application code changes. This prevents an attacker who gains access to the internal network from eavesdropping on or tampering with service-to-service communication.
API Gateways serve as the single entry point for external traffic, handling authentication, rate limiting, request routing, and protocol translation. The gateway routes incoming OpenID4VCI requests to the Issuance Service, OpenID4VP requests to the Verification Service, and status queries to the Status Service, while applying consistent security policies across all endpoints.
The principle of least privilege is enforced at the service level through Kubernetes network policies. Each service can only communicate with the specific services it needs. The Issuance Service can reach the Key Management Service and the credential database, but is blocked from communicating directly with the monitoring stack or the Trust Registry update endpoints.