Cybersecurity glossary
What are Microservices?
Learn what microservices are, how they differ from monoliths, which communication and data patterns they use, and the security challenges of distributed service architectures.
Definition
Microservices are an architectural style that structures an application as a set of small, independently deployable services—each owning a focused business capability and communicating over the network through APIs or messaging.
Why microservices exist
Monoliths are straightforward until release coordination, scaling bottlenecks, and team ownership collide. Different parts of a product need different scale, languages, and deploy cadences.
Microservices respond by splitting the system into independently deployable services around business capabilities. The promise is agility and isolation. The price is distributed-systems complexity—latency, partial failure, and a much larger security perimeter.
Microservices vs monolith
| Aspect | Monolith | Microservices |
|---|---|---|
| Deploy unit | One application package | Many independently released services |
| Data ownership | Often one shared database | Prefer per-service data stores |
| Failure mode | Process crash affects many features | Partial outages; cascading failures possible |
| Security boundary | Mainly north-south edge | Edge plus many east-west service trusts |
| Operational overhead | Lower initially | Higher—discovery, mesh, observability, CI sprawl |
How a microservice request typically flows
Edge receives the external call
API gateway, CDN, or load balancer authenticates and routes to an entry service.
Entry service applies business orchestration
It may handle the request alone or call other services for specialized work.
Service-to-service calls use identity
mTLS, JWT, or mesh identities prove which service is calling which.
Each service owns its data path
Local databases, caches, and queues keep write models independent.
Async events decouple side effects
Messages notify other domains without tight synchronous coupling.
Telemetry stitches the transaction
Trace IDs correlate spans across services for debugging and audit.
Benefits when the style fits
Independent deployability
Teams ship their service without waiting for a single release train.
Targeted scaling
Scale the hot path without cloning the entire application footprint.
Technology flexibility
Choose runtimes that fit each capability—within organizational guardrails.
Fault isolation potential
A failure can stay contained if timeouts, bulkheads, and fallbacks are real.
Security challenges unique to microservices
East-west trust
A compromised service can call others. Authenticate and authorize every internal hop.
Secret sprawl
More services mean more credentials—centralize rotation and least privilege.
Exposed debug surfaces
Actuator, admin, and gRPC reflection endpoints multiply across the fleet.
Inconsistent authz models
Object-level checks must not be “assumed done” by an upstream gateway alone.
SSRF and metadata risks
Services that fetch URLs can reach cloud metadata or internal admin APIs.
Supply chain per service
Each pipeline and base image needs scanning and provenance controls.
Adoption checklist
- Split along stable business boundaries, not arbitrary code folders.
- Require service identity (mTLS or equivalent) for internal calls—no flat open networks.
- Enforce authorization in each service for sensitive operations.
- Standardize timeouts, retries, and idempotency to prevent retry storms.
- Adopt distributed tracing and structured logs with correlation IDs from day one.
- Centralize secrets and policy; avoid long-lived shared API keys between services.
- Define a threat model for the service graph, including lateral movement paths.
- Resist premature decomposition—start with modular monoliths when team scale is small.
The practical takeaway
Microservices break an application into independently deployable services that communicate over the network. They can unlock team autonomy and scaling—but they turn security into a many-hop problem.
Adopt them with strong service identity, consistent authorization, observability, and operational discipline. Without those, you have distributed complexity without distributed safety.
Related security terms
Service Mesh
Infrastructure layer often used for mTLS, retries, and traffic policy between services.
gRPC
A common high-performance RPC choice for service-to-service calls.
API Abuse
External and internal APIs both need abuse controls in microservice estates.
Zero Trust Architecture
A model that fits microservices where network location is not trust.
Load Balancer
Distributes traffic to replicated service instances.
Frequently asked questions
What are microservices in simple terms?
Instead of one big application doing everything, you split the product into smaller services—like billing, login, and notifications—that talk to each other over the network and can be updated separately.
Are microservices always better than a monolith?
No. They add operational and security complexity. They help when teams and scale need independent deployment; they hurt when the domain is small or tooling is immature.
How do microservices communicate?
Usually HTTP/REST, gRPC, or asynchronous messages/events. Synchronous chains can create fragility if overused.
Does each service need its own database?
Often yes for true independence (database-per-service), but shared databases appear in transitional designs and create coupling risks.
What is the biggest security change?
The internal network becomes an attack path. Service identity, mTLS, and authorization between services matter as much as the public edge.
What is a bounded context?
A domain-driven design idea: a clear boundary where a model stays consistent—often used to decide microservice borders.
Can microservices be serverless?
Yes. Independently deployable functions or containers can still follow microservice principles.
References
Explore authoritative guidance and frameworks related to microservices.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.