Service Oriented Architecture (SOA)

- Independent of vendor, product, and technologies.

- Characteristics:
Represent Business activity with specified outcome
Self-contained
Blackbox for its consumers
may consist of other underlying services
- SOA is more about how to compose an application by integration of distributed, separately-
maintained & deployed software components.

Microservices

Benefit
- Reduce the complexity because of the decomposition (Each service can be maintained
separately)
- Each service has its own task and its own DB
- Individual service easier to understand and maintain
- Deploy faster
- Scaled independently
- Each service can use different technologies as long as the API adhere the contract
- Continuous deployment becomes possible

Drawback
- Microservice distributed system increase the complexity
- Invoking a service from one to another via language-level method/procedure calls is more
complex
- There is challenge on partitioned database architecture
- Based on the article, we should use eventual consistency approach more challenging for
developers
- Testing is more complex
- Deploying is more complex

Decompose pattern
- By Business capability
- By subdomain

Database per service pattern how each service has its own database to ensure loose
coupling

Implement Queries -> retrieve data owned by multiple services

- API Composition pattern -> Application perform join rather than database
- Command Query Responsibility Segregation (CQRS) pattern -> materialized views
Data consistency
- Saga pattern
Each Local transaction update the DB & publish a message or event to trigger the next
local transaction in saga
- Benefit : Maintain data consistency accross multiple services without using distributed
transaction
- Drawbacks : Programming model is more complex. Developer must design
compensating transactions that explicitly undo changes made earlier in a saga

Patterns for atomically update state and publish events

- Event sourcing
Persist the state of a business entity as a sequence of state-changing events.
Whenever the state changes -> new event is appended to the list of events.
There is/are subscriber(s) that subscribe to events. When a service saves an event in
the event store, it is delivered to all interested subscribers.
- Application events
Application insert events into an EVENTS table as part of the local transaction
A separate process polls the EVENTS table and publishes the events to a message
broker.
- Database triggers
One or more database triggers insert events into an EVENTS table, which is polled by a
separate process that publishes the events.
- Transaction log tailing
Tail the database transaction log and publish each change as an event.

How client interact with microservices?

API Gateway
Single entry point
Request Routing
Composition
Benefit:
Encapsulate internal application structure
Clients simply talk to the gateway
Simplifies client code
Can mask failures in the backend services by returning cached or default data

Inter-Process Communication (IPC)

Communication between services
Using messaging?? or HTTP??
Handling Partial Failures:
Strategies
Network timeouts : use timeouts when waiting for a response
 Limiting the number of outstanding requests : If the limit has been reached, it is
probably pointless to make additional requests, and those attempts need to fail
immediately.
Circuit breaker pattern : Track the number of successful and failed requests. If
the error rate exceeds a configured threshold, trip the circuit breaker so that
further attempts fail immediately. If a large number of requests are failing, that
suggests the service is unavailable and that sending requests is pointless. After a
timeout period, the client should try again and, if successful, close the circuit
breaker.
Provide fallbacks : Perform fallback logic when a request fails. For example,
return cached data or a default value.
If use JVM, consider using Hystrix. It implements circuit breaker pattern
Hystrix times out calls that exceed the specified threshold.
Hystrix lets us define a fallback action when a request fails, such as reading from a
cache or returning a default value

Service Discovery
Why use service discovery? In order to make a request, the code needs to know the network
location (IP Address & Port) of a service instance.
Traditional application (running on physical hardware)
Network locations of service instances are relatively static Just read the network locations
from a configuration file that is occasionally updated.
Modern cloud-based microservices application (more difficult problem to solve)
Service instances have dynamically assigned network locations. The set of service
instances changes dynamically because of autoscaling, failures, and upgrades.
Consequently, the client code needs to use a more elaborate service discovery mechanism.

Service discovery patterns

1. Client side discovery pattern
The client is responsible for determining the network locations of available service
instances and load balancing requests across them
The client queries a service registry, which is a database of available service instances
The client then uses a load balancing algorithm to select one of the available service
instances and makes a request
Benefit
Relatively straightforward
Since the client knows about the available services instances, it can make intelligent,
application specific load balancing decisions such as using hashing consistently
Drawback
Couples the client with the service registry must implement client side service
discovery logic for each programming language and framework used by your service
clients.

2. Server side discovery pattern

 The client makes a request to a service via a load balancer. The load balancer queries
the service registry and routes each request to an available service instance
Benefit
Details of discovery are abstracted away from the client.
Clients simply make requests to the load balancer. This eliminates the need to
implement discovery logic for each programming language and framework used by
service clients.
Drawback
Highly available system component that we need to set up and manage.

Service Registry
is a database containing the network locations of service instances. A service registry needs to
be highly available and up to date.

Service Registration Options

1. Self-registration pattern
A service instance is responsible for registering and deregistering itself with the service
registry. Also, if required, a service instance sends heartbeat requests to prevent its
registration from expiring.
2. Third-party registration pattern
Another system component known as the service registrar handles the registration. The
service registrar tracks changes to the set of running instances by either polling the
deployment environment or subscribing to events.

Data Management

Single Service per Host & Multiple Services per Host patterns
- deployment strategies

Cross-cutting concern patterns:

- Microservice chassis pattern & Externalized configuration

Testing patterns:
- Service Component Test & Service Integration Contract Test

Circuit Breaker

Access Token

Observability patterns
- Log Aggregation
- Application metrics
- Audit logging
- Distributed tracing
- Exception tracking
- Health check API
- Log deployments and changes

UI patterns:
- Server-side page fragment composition
- Client-side UI composition