Explore

Patterns And Techniques in Service-Oriented Architecture

This article provides an overview of some techniques and patterns for developing applications in service-oriented architecture, together with external resources for more detail explanations. This is not a comprehensive references for all available techniques and patterns, I selected only some patterns that I find useful and have already been applied or will be applied in my projects, I use this article as a quick reminder. For more comprehensive resources, please visit the further readings section.

Application modelling

Domain Driven Design

Summary:

Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. [1]

⁠

(Image Source)⁠

⁠

External resources:

Martin Fowler’s

Bliki on DDD⁠

⁠

Domain-Driven Design: Tackling Complexity in the Heart of Software — Eric Evans⁠

⁠

https://medium.com/the-coding-matrix/ddd-101-the-5-minute-tour-7a3037cf53b8⁠

⁠

Service decomposition techniques

Decomposition by subdomain

Summary:

Define services corresponding to Domain-Driven Design (DDD) subdomains. DDD refers to the application’s problem space — the business — as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

Pattern: Decompose by subdomain — Chris Richardson⁠

⁠

Strangler pattern

Summary:

Modernize an application by incrementally developing a new (strangler) application around the legacy application. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://microservices.io/patterns/refactoring/strangler-application.html⁠

⁠

Martin fowler’s article on the origin of the name of the pattern:

https://martinfowler.com/bliki/StranglerFigApplication.html⁠

⁠

Branch By Abstraction

Summary

Co-exist two implementations of the same functionality in the same running process at the same time. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://samnewman.io/patterns/architectural/branch-by-abstraction/⁠

⁠

https://trunkbaseddevelopment.com/branch-by-abstraction/⁠

⁠

https://martinfowler.com/bliki/BranchByAbstraction.htm⁠

Data management patterns

Database per service

Summary

Keep each microservice’s persistent data private to that service and accessible only via its API. A service’s transactions only involve its database.

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://microservices.io/patterns/data/database-per-service.html⁠

⁠

Change data capturer

Summary

Change data capture (CDC) is a set of software design patterns used to determine and track the data that has changed so that action can be taken using the changed data.CDC is an approach to data integration that is based on the identification, capture and delivery of the changes made to data sources.[1]

⁠

(

Image: Debezium architecture⁠

)

External resources:

⁠

https://en.wikipedia.org/wiki/Change_data_capture⁠

⁠

https://debezium.io/blog/2020/02/10/event-sourcing-vs-cdc/⁠

⁠

Saga pattern

Summary

Implement each business transaction that spans multiple services is a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://microservices.io/patterns/data/saga.html⁠

⁠

Transactional outbox pattern

Summary

How to reliably/atomically update the database and publish messages/events?

A service that uses a relational database inserts messages/events into an outbox table (e.g. MESSAGE) as part of the local transaction. A separate Message Relay process publishes the events inserted into database to a message broker. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://microservices.io/patterns/data/transactional-outbox.html⁠

⁠

https://debezium.io/blog/2019/02/19/reliable-microservices-data-exchange-with-the-outbox-pattern/⁠

⁠

Synchronous communication patterns

API Gateway

Summary:

An API gateway is a service which is the entry point into the application from the outside world. It’s responsible for request routing, API composition, and other functions. [1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://freecontent.manning.com/the-api-gateway-pattern/⁠

⁠

https://microservices.io/patterns/apigateway.html⁠

⁠

Retry

Summary

Enable an application to handle transient failures when it tries to connect to a service or network resource, by transparently retrying a failed operation. This can improve the stability of the application.[1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/retry⁠

⁠

Circuit breaker

Summary

A circuit breaker acts as a proxy for operations that might fail. The proxy monitors the number of recent failures that have occurred, and use this information to decide whether to allow the operation to proceed, or simply return an exception immediately.[1]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker⁠

⁠

Back pressure & Throttling

Summary

Back pressure: When one component is struggling to keep-up, the system as a whole needs to respond in a sensible way. It is unacceptable for the component under stress to fail catastrophically or to drop messages in an uncontrolled fashion. Since it can’t cope and it can’t fail it should communicate the fact that it is under stress to upstream components and so get them to reduce the load. [1]

Throttling: The system should monitor how it’s using resources so that, when usage exceeds the threshold, it can throttle requests from one or more users. This will enable the system to continue functioning and meet any service level agreements (SLAs) that are in place. [3]

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://www.reactivemanifesto.org/glossary#Back-Pressure⁠

⁠

https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7⁠

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/throttling⁠

⁠

Service mesh

Summary

Service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between microservices, often using a sidecar proxy. [1]

⁠

(

Image: Istio Architecture⁠

)

External resources:

⁠

https://en.wikipedia.org/wiki/Service_mesh⁠

⁠

https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh⁠

⁠

Istio, Shopee’s SPEX and Hashicorp’s Consul are some implementation of service mesh.

Asynchronous communication patterns

Publish-Subscribe

Summary:

Publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers there are.

⁠

(Image: Kafka)⁠

⁠

External resources:

⁠

https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern⁠

⁠

https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html⁠

⁠

Dead-letter channel

Summary:

What will the messaging system do with a message it cannot deliver? When a messaging system determines that it cannot or should not deliver a message, it may elect to move the message to a Dead Letter Channel. [1]

⁠

(Image source)⁠

⁠

External resources:

⁠

https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html⁠

⁠

Competing consumers

Enable multiple concurrent consumers to process messages received on the same messaging channel.

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html⁠

⁠

Idempotent consumers

Implement an idempotent consumer, which is a message consumer that can handle duplicate messages correctly. Some consumers are naturally idempotent. Others must track the messages that they have processed in order to detect and discard duplicates. [1]

External resources:

⁠

https://microservices.io/patterns/communication-style/idempotent-consumer.html⁠

⁠

Event message:

Use an Event Message for reliable, asynchronous event notification between applications.

External resources:

⁠

https://www.enterpriseintegrationpatterns.com/patterns/messaging/EventMessage.html⁠

⁠

Command message:

Use a Command Message to reliably invoke a procedure in another application.

External resources:

⁠

https://www.enterpriseintegrationpatterns.com/patterns/messaging/CommandMessage.html⁠

⁠

Application Design & Development

Twelve factors applications

Summary: [1]

The twelve-factor app is a methodology for building software-as-a-service apps that:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;

Have a clean contract with the underlying operating system, offering maximum portability between execution environments;

Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;

Minimize divergence between development and production, enabling continuous deployment for maximum agility;

And can scale up without significant changes to tooling, architecture, or development practices.

Twelve factors:

Codebase: One codebase tracked in revision control, many deploys

Dependencies: Explicitly declare and isolate dependencies

Config: Store config in the environment

Backing services: Treat backing services as attached resources

Build, release, run: Strictly separate build and run stages

Processes: Execute the app as one or more stateless processes

Port binding: Export services via port binding

Concurrency: Scale out via the process model

Disposability: Maximize robustness with fast startup and graceful shutdown

Dev/prod parity: Keep development, staging, and production as similar as possible

Logs: Treat logs as event streams

Admin processes: Run admin/management tasks as one-off processes

External Resources:

⁠

https://12factor.net/⁠

⁠

Cloud-Native Applications

Summary:

Cloud native computing is an software development approach that utilizes cloud computing to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds [3]

Cloud-Native Principles [1]:

If a project is cloud native, it uses immutable infrastructure, declarative apis, and microservices.

If infrastructure is immutable, it is easily reproduced, consistent, disposable, will have a repeatable deployment process, and will not have configuration or artifacts that are modifiable in place.

If a project has an efficient and repeatable deployment process, its process is versioned, automated, and has low overhead/coarse grained packaging.

If a project’s deployment is automated, configuration, environment, and artifacts are completely managed by a pipeline.

If a projects deployment is managed completely by a pipeline, the project’s environment is protected.

If a project’s environment is protected, it provides observability of the project’s internal components.

If a project’s uses declarative APIs, its configuration is declarative.

If a project’s configuration is declarative, it designates what to do, not how to do it.

If a project exists as a microservice, it is not monolithic, it is resilient, it follows 12-factor principles, and is discoverable.

If a microservice is resilient, it is self-healing and distributed.

External Resources:

⁠

https://networking.cloud-native-principles.org/cloud-native-principles⁠

⁠

https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/introduction⁠

⁠

https://en.wikipedia.org/wiki/Cloud_native_computing⁠

⁠

Feature flags

Summary:

Feature flags (also known as

feature toggles⁠

or feature switches) are a software development technique that turns certain functionality on and off during runtime, without deploying new code. This allows for better control and more experimentation over the full lifecycle of features. [2]

⁠

External Resources:

⁠

https://martinfowler.com/articles/feature-toggles.html⁠

⁠

https://www.optimizely.com/optimization-glossary/feature-flags/⁠

⁠

https://featureflags.io/⁠

⁠

Deployment and Operation

Deployment strategies: Rolling update, red/black, canary.

Summary:

⁠

(Image: Spinnaker’s deployment strategies)⁠

⁠

External resources:

⁠

https://docs.cloudbees.com/docs/cloudbees-cd/latest/deploy-automation/deploystrategy⁠

⁠

https://rollbar.com/blog/deployment-strategies/⁠

⁠

External Configuration Store

Summary:

Move configuration information out of the application deployment package to a centralized location. This can provide opportunities for easier management and control of configuration data, and for sharing configuration data across applications and application instances.

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store⁠

⁠

https://www.consul.io/⁠

⁠

Let it crash

Summary:

Prefer a full component restart to internal failure handling.

External resources:

⁠

https://dzone.com/articles/increasing-system-robustness⁠

⁠

Release It! 2nd Edition

Sidecar pattern

Co-locate a cohesive set of tasks with the primary application, but place them inside their own process or container, providing a homogeneous interface for platform services across languages.

⁠

(Image Source)⁠

⁠

External resources:

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar⁠

⁠

https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/⁠

⁠

Observability

USE & RED method:

Summary:

USE method: For every resource, check utilization, saturation, and errors. [1]

Utilization: the average time the resource was busy servicing work

Saturation: the degree to which the resource has extra work which it can’t service, often queued

Errors: the count of error events

RED method: With the RED method, three key metrics are instrumented that monitor every service in your architecture [2]:

(Request) Rate — the number of requests, per second, your services are serving.

(Request) Errors — the number of failed requests per second.

(Request) Duration — The amount of time each request takes expressed as a time interval.

External Resources:

⁠

https://orangematter.solarwinds.com/2017/10/05/monitoring-and-observability-with-use-and-red/⁠

⁠

https://www.weave.works/docs/cloud/latest/tasks/monitor/best-instrumenting/⁠

⁠

Health Endpoint Monitoring

Summary:

Implement health monitoring by sending requests to an endpoint on the application. The application should perform the necessary checks, and return an indication of its status.

External Resources:

⁠

https://docs.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring⁠

⁠

Release It! 2nd edition

Logging, Metrics Monitoring, Error Tracking, and Distributed Tracing

Summary: [1]

⁠

Tracing⁠

, aka distributed tracing, provides insight into the full lifecycles, aka traces, of requests to the system, allowing you to pinpoint failures and performance issues.

⁠

Metrics⁠

provide quantitative information about processes running inside the system, including counters, gauges, and histograms.

⁠

Logging⁠

provides insight into application-specific messages emitted by processes.

External Resources:

⁠

https://opentelemetry.io/⁠

⁠

https://sentry.io/welcome/⁠

⁠

Patterns And Techniques in Service-Oriented Architecture

Application modelling

Domain Driven Design

Service decomposition techniques

Decomposition by subdomain

Strangler pattern

Branch By Abstraction

Data management patterns

Database per service

Change data capturer

Saga pattern

Transactional outbox pattern

Synchronous communication patterns

API Gateway

Retry

Circuit breaker

Back pressure & Throttling

Service mesh

Asynchronous communication patterns

Publish-Subscribe

Dead-letter channel

Competing consumers

Idempotent consumers

Event message:

Command message:

Application Design & Development

Twelve factors applications

Cloud-Native Applications

Feature flags

Deployment and Operation

Deployment strategies: Rolling update, red/black, canary.

External Configuration Store

Let it crash

Sidecar pattern

Observability

USE & RED method:

Health Endpoint Monitoring

Logging, Metrics Monitoring, Error Tracking, and Distributed Tracing

Further Reading