What is microservice?

A microservice is a small, independent piece of software that does one specific job. Instead of building one huge application that does everything, you build many tiny services, each handling a single function (like user login, payment processing, or sending emails). These services talk to each other over a network, usually using simple web calls.

Let's break it down

  • Small: Each service is kept tiny so it’s easy to understand and change.
  • Independent: It can be developed, deployed, and scaled without touching the other services.
  • Single purpose: One service = one business capability (e.g., “search products”).
  • Communicates via APIs: Services talk through well‑defined interfaces, often HTTP/REST or messaging queues.
  • Own data: Each microservice usually has its own database, so it doesn’t share tables with others.

Why does it matter?

Microservices let teams work faster because they can focus on one piece at a time. If one service has a bug or needs more resources, you can fix or scale it without shutting down the whole system. This flexibility makes it easier to adopt new technologies, improve reliability, and respond to changing user needs.

Where is it used?

  • Online retailers (e.g., Amazon) use separate services for catalog, checkout, recommendations, and shipping.
  • Streaming platforms (e.g., Netflix) split video encoding, user profiles, and recommendation engines into different services.
  • Financial apps isolate payment processing, fraud detection, and account management.
  • Mobile back‑ends often break out authentication, push notifications, and data sync into microservices.
  • Large enterprises adopt microservices when modernizing legacy monolithic systems.

Good things about it

  • Scalability: Only the busy services need more compute power.
  • Fault isolation: A crash in one service usually doesn’t bring down the whole app.
  • Technology diversity: Teams can pick the best language or framework for each service.
  • Faster deployments: Small services can be released more often with less risk.
  • Team autonomy: Different teams can own different services and work in parallel.

Not-so-good things

  • Complexity in coordination: Managing many services, their versions, and network calls can be tricky.
  • Operational overhead: You need infrastructure for service discovery, load balancing, monitoring, and logging.
  • Data consistency: Keeping data synchronized across separate databases is harder than in a single monolith.
  • Testing challenges: End‑to‑end tests must involve multiple services, which can be slower and more fragile.
  • Increased latency: Calls over the network add delay compared to in‑process method calls.