Understanding Microservice Architecture and Its Core Characteristics

Microservices provide a single, highly specialized function accessed via remote APIs; for example, a warehouse management system might include services that receive inventory, calculate storage locations, plan routes, assign routes to staff, receive orders, compute picking routes, and assign those routes.

Receive inventory

Calculate where new inventory should be stored

Compute routes to move inventory to the correct placement points

Assign transport routes to warehouse staff

Receive orders

Calculate picking routes for a set of orders

Assign picking routes to warehouse staff

Each microservice runs in its own thread, can be deployed independently, and typically has its own dedicated database while still collaborating with other services.

Different microservices may be implemented on various platforms—some in .NET, others in Erlang or Node.js—as long as they can communicate; HTTP is a widely supported protocol, though queues, service buses, or binary protocols like Thrift are also viable.

For instance, a "Pick‑Route Assignment" microservice receives a request from another service, searches its database for an appropriate route, and returns that route to the caller.

What is microservice architecture?

Microservice architecture is a lightweight, service‑oriented style where each service focuses on doing one thing well. A system built with microservices consists of many coordinated, distributed services, each owning its own process and data store, communicating via platform‑agnostic mechanisms such as HTTP.

Microservices have become popular for building complex server‑side systems because, compared with monolithic architectures, they offer greater flexibility, scalability, and resilience, allowing rapid development from code to production.

Key characteristics of microservices

1. Responsible for a single function 2. Independently deployable 3. Consist of one or more processes 4. Own data storage 5. Maintainable by a small team 6. Replaceable

The single‑responsibility principle applies at the service level: a microservice should change only when its specific business capability changes.

Independent deployment

Each microservice can be updated and deployed without affecting the rest of the system, enabling low‑risk, rolling deployments and allowing other services to continue operating while one service is upgraded.

One or more processes

A microservice may run multiple processes—for example, a recommendation service might have a process for the algorithm and another for its database—so that the service can fully implement its functionality.

Own data storage

Having its own database lets a microservice choose the most suitable storage technology (SQL, Redis, Elasticsearch, etc.) and keeps data ownership encapsulated, preventing other services from accessing the data directly.

Small‑team maintainability

A microservice should be small enough that a team of about five people can maintain it, handling development, scaling, monitoring, testing, and bug fixing.

Replaceability

If a microservice grows too large, the cost of rewriting it becomes prohibitive; keeping services small ensures they can be rewritten within a reasonable timeframe when needed.