Skip to content

Service-Oriented Architecture


  • SOA is an architectural style where software is built as a collection of loosely coupled, reusable services.
  • Each service performs a specific business function (e.g., payment processing, user authentication) and communicates through well-defined interfaces (protocols like SOAP, REST, JMS).

  1. Services

    • Independent units of functionality (e.g., Get Customer Details).
    • Reusable across different applications.
  2. Loose Coupling

    • Services don’t depend on internal details of each other — only the contract/interface.
  3. Interoperability

    • Services can interact regardless of platform/language (Java, .NET, Python).
  4. Service Contract

    • Describes what the service does (via WSDL in SOAP, or OpenAPI/Swagger in REST).
  5. Discoverability

    • Services can be registered and discovered by other applications (e.g., UDDI in classical SOA).

Imagine an e-commerce system:

  • OrderService → Place, track, cancel orders
  • PaymentService → Handle payments
  • ShippingService → Arrange delivery

They all work independently but together form the business flow.


Pros: ✅

  • Reusability
  • Scalability & Maintainability
  • Technology agnostic
  • Supports distributed systems

Cons: ⚠️

  • Higher complexity
  • Performance overhead (due to network calls)
  • Requires governance

What is SOA?

  • An architecture style that organizes software into reusable, loosely coupled services accessible over standard protocols.

How SOA is different from Monolithic architecture?

  • SOA breaks applications into independent services communicating over standard protocols, while monolithic apps are tightly coupled and deployed as a single unit.

What is the relationship between SOA and Microservices?

  • Microservices are an evolution of SOA — smaller, independently deployable, with lighter communication (REST/HTTP instead of SOAP/ESB).

Difference between SOA and Microservices?

  • SOA uses coarse-grained services often connected via ESB, while Microservices are smaller, independently deployable, and typically use REST/HTTP.

Why is loose coupling important?

  • It allows services to evolve independently, reduces dependencies, and increases flexibility.