Introduction

Definition of Microservices:

A type of service oriented architecture where the services are independently deployable and boundaries are primarily defined by the business domain.

Keywords from the definition above:

• service-oriented architecture => a set of collaborating services which typically run on different computers, with communication between them done via network-based protocols.
• independently deployable => the unit of release (architecture quanta) is a single microservice
• business domain => the structure of the business domain guides the structure of the architecture. The business domain defines the boundaries between microservices

Distributed Systems

3 Golden Rules of distributed computing:

1. You can’t beam information between 2 points instantly
2. Sometimes, you can’t reach the point you want to talk to
3. Resource pools are NOT infinite: CPU, network utilisation, memory, disk space

Communication Styles

2 main communication styles:

1. Request/Response
   
2. Event-driven
   

A microservice can expose multiple endpoints with different communication styles. Separation of private and public API endpoints allows for best mix of communication protocols in the system, e.g. REST on public, GRPC & pub/sub on private.

Defining Boundaries

Backwards compatibility is key in having independent deployability in microservices.

Anything hidden can change as needed

Anything exposed becomes part of your service interface

Information Hiding

Information hiding holds an important role to ensure backward compatibility.

Be explicit about what is hidden and what is shared

The more you hide: the easier it is to maintain backward compatibility and achieve independent deployability.

Consumer-First Mindset

Consumer-first mindset helps us in deciding which information to hide.

This brings us to have an outside-in thinking rather than inside-out thinking. That is, we treat our microservice endpoints like a User Interface (UI):

• who is going to consume your microservices?
• what are they trying to achieve?
• what SLOs (Service Level Objectives) do your clients need?
• what interface makes their jobs easier?
• what are their requirements in terms of availability and latency?

Understand your consumers and what they want, design an endpoint that only exposes what they need.

Schema-First Design (or Contract-First Design)

Schema-first design provides consumers of your microservices with explicit schemas. It opens communication with your customers in understanding what they need.

Common use cases:

• GraphQL APIs: Using SDL (Schema Definition Language) to define types.
• REST APIs: Using OpenAPI (Swagger) specifications.
• gRPC APIs: Using Protocol Buffers (.proto files).

Synchronous vs Asynchronous

Synchrounous vs Asynchronous communication can mean 2 things:

1. Blocking vs non-blocking calls
2. Temporal de-coupling

Blocking vs Non-blocking Calls

Blocking calls => when the execution of a program needs to wait for the response from a service. Thus, the latency is the total sum of the calls.

To achieve non-blocking calls, we need to do the calls in parallel on separate thread. However, program execution might still need to wait at some point when the response is needed but not yet available.

Temporal Decoupling

Temporal coupling => when two or more processes have to be up and available at the same time for an operation to complete.

To achieve temporal decoupling, we can use intermediaries such as a broker.

It is arguable that the intermediary-based communication encourages stateless processing as a response can be received by a different instance:

Summary

Sagas

Saga patterns are considered highly suitable for microservices because they solve one of the biggest problems in distributed systems: How do you maintain business consistency across multiple independent services without using a giant distributed transaction?

In a monolith, a single ACID database transaction can coordinate everything.

In microservices, ACID transaction cannot be achieved:

• each service owns its own database
• services are independently deployable
• networks are unreliable
• distributed transactions are expensive and fragile

Also, 2-Phase Commit (2PC) causes problems in microservices architecture:

• Blocking: services hold locks while waiting to commit
• Poor performance: multiple network round trips and synchronous coordination increase latency

Sagas provide a practical way to coordinate workflows across services while preserving service autonomy:

• Orchestration or Choreographed coordination
• Compensating updates as business-level logic, rather than infrastructure (database) concern, when failure happens

See more information here

Key Technologies

API Gateways

API Gateways act like networking gateway (bridging 2 networks) with additional features around API access.

About API gateways:

API Gateways are a vendor product - you don’t want your core system smarts in there

“Keep your endpoints smart, and your pipes dumb”

Treat API gateways like a dumb pipe!

Service Meshes

A service mesh is an infrastructure layer that manages communication between microservices.
Instead of implementing networking concerns inside each service, these concerns are delegated to lightweight network proxies (sidecars) managed by the mesh.

Traditional microservices often duplicate networking logic such as:

• retries
• timeouts
• TLS
• load balancing
• circuit breaking
• metrics
• tracing

A service mesh centralizes these concerns.

Mutual TLS is mostly useful on Kubernetes when using service mesh. A control plane is used to manage sidecars spread around the system, e.g. certificate distribution, etc.

When to use:

• Hugely beneficial for mutual TLS on Kubernetes
• Especially useful for platform teams, and in polyglot environments
• Can be a requirement for other tech (e.g. KNative)

Message Brokers

In request/response communication, message brokers allows offloading workload with guaranteed delivery:

In event-driven communication, message brokers keep tracks of which subscribers have received which events:

When to use message brokers:

• Reduce/eliminate temporal coupling with your own services
• Offload some of the work for guaranteed delivery
• Especially useful for event-driven interactions

Retries, Timeouts and Latency

Timeouts

Timeouts => a threshold after which a request will be terminated if not completed.

Why timeout:

• resources: the longer you wait, the more resources are used
• recovery: if something is going to fail, you want to fail fast

Timeout management:

1. Understand normal system performance to determine timeout value, e.g. latency distribution chart within your observability tools
2. Error on the side of caution
3. Ensure you can change timeout independent of software releases
4. Keep observing!

Retries

#1 in the fallacies of distributed computing is that the network is NOT 100% reliable.

Idempotency Operations

=> an operation that can be applied multiple times WITHOUT changing the result.

Idempotency operations allows multiple retries as a safe mechanism to deal with timeouts or unreliable network.

For example, this can be achieved by specifying an operation ID in the request.

Latency

Microservices architecture suffers in latency due to lots of network hops.

How to improve latency in microservices architecture:

• Be aware of what takes time
• Don’t hide the network (latency) in architecture diagrams
• Run operations in parallel
• Don’t make calls
• Use different technology
• Merge things back together

Technology Links

• Protobuf is 5-6 times faster than JSON
• Simple Binary Encoding (SBE) is more efficient than Protobuf
• Linkerd
• Istio
• Temporal
• Specmatic
• Confluent - schema management
• OpenAPI-diff
• HTTP/3 = HTTP/2 over QUIC
• QUIC

Resource

• Microservices Comms Styles and Patterns: Microservice Collaboration - Live Event by Sam Newman
• Building Microservices by Sam Newman

Expected Outcomes

[ ] Differentiate between an architectural style and a pattern, and understand how they fit together in software architecture [ ] Identify patterns that you can use to tackle common architecture problems [ ] Discover antipatterns to avoid in software architecture [ ] Determine the proper communcation style to derive the most benefit from a particular architecture pattern

We will learn: [ ] Key architectural patterns used within modern software architectures [ ] The strengths and trade-offs associated with each pattern [ ] Antipatterns to avoid when architecting software

Introduction

An architectural pattern, much like a design pattern, is a reusable solution to problems an architect commonly encounters when designing systems. Exposure to architecture patterns, and knowing how to leverage them appropriately, are critical foundational skills for all architects.

Gaining a solid understanding of architectural patterns and a valuable toolkit to enhance your capability as a software architect is fundamental. Also is the case with knowing the differences between architectural styles (such as layered and microservices) and architectural patterns (such as messaging and caching patterns). With that foundation, we’ll delve into a variety of architectural patterns, their ideal applications, and the trade-offs each pattern presents. We’ll also explore emerging patterns and antipatterns in AI.

Definitions

Architecture pattern = contextualised solution to an architectural problem.

Architecture patterns affects topology and capabilities of the solution.

Anti-pattern = a solution that looks like a pattern but turns out to do more damage than benefit.

Architecture Patterns

Workflow Patterns

Orchestration

Ideal Applications

Trade-offs

Choreography

Ideal Applications

Trade-offs

Hybrid

Ideal Applications

Trade-offs

Broker Patterns

Domain Broker Pattern

Ideal Applications

Trade-offs

Multi-Broker Pattern

Ideal Applications

Trade-offs

Event Contract Patterns

Data-based Contract Pattern

Characteristics:

• We transfer hydrated contract to each service

Key-based Contract Pattern

Characteristics:

• We only transfer the values each service needs
• We touch the DB a lot

Comparison

Anti-Patterns

Grain-of-Sand Anti-pattern

How small should your microservices be?

Swarm-of-Gnats Anti-pattern

=> Triggering multitude events based on multiple state changes or actions.

The higher granularity a system has:

• The more fault tolerant the system is
• The lower the performance is due to multiple inter-service communication

There are some disintegrators and integrator that can be used to help break down and consolidate services. More information can be found here:

Consolidating several services into 1 can be a good answer to avoid swarm-of-gnats anti-pattern. Indication of this is when an event triggers all the relevant services, or none of the relevant services.

Data Ownership Patterns

Owner of a table is whoever writes to the table.

3 kinds of ownership:

1. Single
2. Joint
3. Common

Single

1 owner => the service can be a microservice (highest data fidelity)

Joint

2 owners => options: a. Table split: clear separation and services can become microservices. A communication channel between the 2 services is needed. b. Data domain: table become individual domain c. Delegation: one service takes ownership and the other communicates with it d. Consolidation: integrating 2 services into 1 microservice

Common

2 owners => create a (proxy) service to be the owner

Data transfer (i.e. read data I don’t own):

1. Interservice communication
2. Data replication
3. In-Memory Replicated Cache
4. Sidecar Distributed Cache
5. Data Domain

Interservice communication

Data replication

In-Memory Cache

Sidecar Distributed Cache

Data Domain (Shared Tables)

Use Case

| Option | Best For | |——–|———-| | Interservice communication | ✅ large data volume
✅ low responsiveness | | Data schema replication | ✅ reporting
✅ data aggregation | | In-memory replicated cache | ✅ low data volume
✅ high responsiveness | | Data sidecar distributed cache | ✅ large data volume
✅ high responsiveness | | Data domains (shared tables) | ✅ high responsiveness
✅ data dependencies |

Summary of Data Ownership Patterns

Caching Patterns

Caching topologies:

1. Single in-memory cache
2. Distributed (client/server) cache
3. Replicated (in-process) cache
4. Near-cache hybrid

Cache-aside

The application is the orchestrator for both read and write processes, i.e. the application is aware of both cache and datastore and which operation goes to where.

Read:

• When data available in cache, it takes 4 steps
• In the event of a cache-miss, it takes 6 steps. This involves lazy-loading the cache with the missing data.

Write: takes 4 steps

Use case:

• read-heavy loads
• content delivery systems
• reporting systems

Star rating: | Capability | With Pattern | Without Pattern | |—|:—:|:—:| | Flexibility | ★★★★★ | ★★★ | | Scalability | ★★★★ | ★★ | | Read Throughput | ★★★★★ | ★★ | | Write Throughput | ★★★★ | ★★★★★ | | Cost | ★★★★ | ★★★★★ | | Responsiveness | ★★★★ | ★★ | | Consistency | ★★ | ★★★★★ | | Simplicity | ★★★ | ★★ |

Influences in caching topologies: | Capability | Single In-Memory Cache | Client-Server Cache (Remote) | Replicated In-Memory Cache | |—|:—:|:—:|:—:| | Flexibility | ★★★★★ | ★★★★ | ★★★★ | | Scalability | ★★ | ★★★★ | ★★★★★ | | Read Throughput | ★★★★★ | ★★★ | ★★★★★ | | Write Throughput | ★★★★ | ★★★ | ★★★ | | Cost | ★★ | ★★★★ | ★ | | Consistency | ★★ | ★★★★ | ★★★ | | Simplicity | ★★★ | ★★★ | ★ | | Responsiveness | ★★★ | ★★ | ★★★★ |

Write Around

Read: same as cache-aside

Write: takes 5 steps ?? Write-around skips writing to the cache altogehter??? Or, delete the relevant data?

Use case:

• write-heavy systems

Read/Write Through

The cache is the orchestrator for both read and write processes, i.e. as far as the application concerns, the cache is the only touch-point for data.

Read:

• When data available in cache, it takes 4 steps just like cache-aside
• In the event of a cache-miss, it takes 6 steps just like cache-aside but via cache

Write: takes 4 steps

Use case:

• high consistency
• critical applications
• read-heavy systems

Star rating: | Capability | Using Read-Through/Write-Through | Without the Pattern | |—|:—:|:—:| | Consistency | ★★★★ | ★★★★★ | | Responsiveness (Reads) | ★★★★ | ★★ | | Read Throughput | ★★★★ | ★★ | | Simplicity | ★★★★ | ★★ | | Scalability | ★★★ | ★★ | | Flexibility | ★★ | ★★★ | | Cost | ★★ | ★★★ | | Write Throughput | ★★ | ★★★ | | Responsiveness (Writes) | ★★ | ★★★ |

Influences in caching topologies: | Capability | In-Memory | Client-Server | Replicated In-Memory | |—|:—:|:—:|:—:| | Consistency | ★★ | ★★★★ | ★★★ | | Responsiveness | ★★★★ | ★★★ | ★★★★ | | Read Throughput | ★★★★★ | ★★★ | ★★★★★ | | Write Throughput | ★★ | ★★ | ★★★ | | Scalability | ★★ | ★★★★ | ★★★★★ | | Simplicity | ★★★ | ★★★★ | ★★ | | Flexibility | ★★★ | ★★ | ★★★ | | Cost | ★★ | ★★★ | ★★ |

Write Behind

Write: takes 3 steps + async write

Use case:

• batch-processing applications
• write-heavy systems

Prompt caching

With LLM, each time a user send a message, user prompt and system prompt are sent. However, system prompt don’t change. Hence, the system prompt is cache in the first instance. The 2nd time the user sends a message, the system will take the system prompt from cache and send both the system prompt and user prompt to LLM.

Use case:

• large system prompts

Summary of Caching Patterns

Continuous Delivery / DevOps Patterns

12/15 Factor App principles

	Principle	Summary	Diagram
1	Codebase	One codebase tracked in version control, many deploys
2	Dependencies	Explicitly declare and isolate dependencies
3	Config	Store config in the environment, not in code
4	Backing Services	Treat backing services (DB, cache, queue) as attached resources
5	Build, Release, Run	Strictly separate build and run stages
6	Processes	Execute the app as one or more stateless processes
7	Port Binding	Export services via port binding
8	Concurrency	Scale out via the process model
9	Disposability	Maximise robustness with fast startup and graceful shutdown
10	Dev/Prod Parity	Keep development, staging, and production as similar as possible
11	Logs	Treat logs as event streams
12	Admin Processes	Run admin/management tasks as one-off processes
13	API First
14	Telemetry
15	Authorisation/Authentication			defence_in_depth_layers
15	Defence in depth layers

User case:

• cloud-nativeability
• security
• scalability
• resilience
• observability

Deployment Strategies

3 deployment strategies:

1. Rolling deploys => one environment at a time
2. Blue-green => 2 sets of environments: blue (live) and green (new features)
3. Canary releases => hybrid between the 2: rolling traffic percentage between 2 sets of environments (blue and green) Benefits of canary release:
   • reduced risk of release
   • multi-variant testing
   • performance testing

AI Patterns

RAG (Retrieval Augmented Generation)

Few-Shot Prompting

=> guided prompting technique using 2-5 examples for a new similar task.

Dynamic Few-Shot Prompting

On-Device LLM Inference

Benefits:

• more secure handling of sensitive data
• extremely low latency (including video processing)
• reduced cost
• better reliability

LLM-as-Judge

AI Anti-patterns

Halucinated Dependencies as Attack Factor

=> a potential security attack by bad actors due to dependency containing malicious code.

Architecture Anti-Patterns

Architecture by Implication

=> system lacking a clear documented architecture.

Some important details in architecture documents:

• What architecture pattern are you using?
• What client model is most appropriate?
• Which platform is best for this solution?
• Does the hardware or os matter?
• How will you handle component integration?
• Which communication protocols should you use?
• Is the solution feasible given skills, budget, and time?
• How secure does the system need to be?
• Does the system need to scale?
• How much performance is needed from the system?
• How available does the system need to be?
• Do you need to be concerned about maintainability?

Gold Plating

=> continuing to define the architecture well past the point which the extra effort is adding any value

• Too many details hide the core principles and standards commonly leads to the analysis paralysis anti-pattern in that the initial architecture is never actually released
• Adding gold plating to a well-defined architecture significantly increases costs with little or no value
• A complex and overly-detailed architecture is hard to understand and comprehend => no “big picture”

Covering Your Assets

=> continuing to document and present alternatives without ever making an architecture decision.

Architect’s job: present alternatives, articulate the pros and cons, and recommend best solution.

Vendor King

=> product-dependent architectures leading to a loss of control of architecture and development costs.

Avoidance techniques:

• treat vendor app as a service (integration point), not the central of your system
• anti-corruption layer using message bus

Witches Brew

=> architectures are designed by groups resulting in a complex mixture of ideas and lack of clear vision

Big Bang Architecture

=> designing the entire architecture at the beginning of the project when you know least about the system.

• Only architect what is absolutely necessary to get the project started and on the right track
• Let the architecture evolve throughout the project as you discover and learn more about the system
• Don’t forget - requirements, technology, and business needs change constantly - and so must the architecture

Armchair Architecture

=> whiteboard sketches are handed off as final architecture standards without proving out the design. Be an integral part of your development team!!

• occurs when you have non-coding architects
• occurs when architects are not involved in the full project lifecycle
• occurs when architects don’t know what they are doing
• stay current and try to carve out some coding for yourself, even if it is proof-of-concept code
• the best architects are the ones who have been in the trenches themselves and know the fallout from bad architecture decisions
• be careful not to release architecture decisions and standards too early

Infinity architecture

=> creating architectures and interfaces that are overgeneralized with infinite flexibility.

• generalized architectures that solve every possible need are expensive and difficult to maintain and change - “we may need…”
• instead, use domain-specific architectures to reduce architecture and system scope

Playing With New Toys

=> incorporating unproven technologies into an architecture that don’t really fit the problem at hand.

when introducing a new technology, ask yourself:

• purpose: what value is it delivering?
• proven: is this a proven technology for your situation?
• overlap: is there something we have that is already supplying this functionality?
• feasibility: does your team have the skills necessary for the technology?

Groundhog Day

• critical architecture decisions made early on are lost, forgotten, or not communicated effectively

Symptoms and consequences:

• people forget or don’t know a decision was made
• the same decision keeps getting discussed and made over and over and over…
• no one understands why a decision was made and they begin to question it again and again…

Avoidance technique:

• capture all important architecture decisions in some sort of work product (doc, wiki, etc.) and make it centrally available
• make sure the right stakeholders know about critical decisions and where to find them

Spider Web Architecture

=> creating large numbers of web services that are never used just because you can.

• just because you can create a web service at the click of a button doesn’t mean you should!
• let the requirements and business needs drive what services should be exposed

Stovepipe Architecture

=> an ad-hoc collection of ill-related ideas, concepts, and components that leads to a brittle architecture.

Architecture by Implication anti-pattern combined with Witches Brew anti-pattern often leads to Stovepipe Architecture anti-pattern.

Symptoms and consequences:

• lack of proper abstraction
• lack of an integration solution
• lack of architecture guidance
• architectures that are difficult to change, difficult to maintain, and break every time you change something

Modern Trade-off Analysis

Use qualitative analysis to iterate on design, leading to quantitative analysis.

A business driver will translate to a set of architectural characteristics which lead to an analysis trade-off by an architect:

Example:

2 useful principles: | Feature | Goldilock Principle | Good-enough Principle | |—|—|—| | Goal | Find the optimal/exact “sweet spot” | Stop at “sufficient” to save time/energy | | Metaphor | “Just right” | “Done is better than perfect” | | Main Use | Balancing variables (e.g., stress, speed) | Decision-making and productivity|

Architecture styles and their best characteristics:

Diagram for trade-off analysis:

For example, if the desired architecture characteristics are maintainability, testability, and deployability, then the best architecture style for this scenario is microservices, followed by service-based, event-driven, and space-based:

To build your own qualitative analysis:

1. Choose a suitable scale: e.g. 5 stars => 20% per star
2. Choose high value criteria

Architecture Fitness Function

=> provides an objective integrity assessment of some architectural characteristic(s).

Software Architecture Laws

1. Everything is a trade-off. Correlation to this is that the architecture analysis inever done just once.
2. Why is more important than how
3. Most architecture decisions aren’t binary but rather exist on a spectrum between extremes

Source

Live Events:

• Software Architecture Patterns and Antipatterns by Neal Ford and Raju Gandhi

Books:

• Software Architecture Patterns, Antipatterns, and Pitfalls by Mark Richards, Neal Ford, Raju Gandhi
• [Software Architecture: The Hard Parts by Mark Richards, Neal Ford, Pramod Sadalage, Zhamak Dehghani]((https://learning.oreilly.com/library/view/software-architecture-the/9781492086888/)

→ the degree of interdependence between software modules and components.

There are two types: static and dynamic.

Static Coupling

→ fixed, code/deployment-level dependencies.

Example: a shared library, or direct code references — regardless of whether services are actively communicating.

Dynamic Coupling

→ runtime dependencies.

Example: when Service A calls Service B synchronously, A becomes temporarily coupled to B’s:

• Availability — if B is down, A fails too
• Performance — if B is slow, A is slow
• Error behaviour — B’s errors propagate directly to A

Transactional Coupling

→ data processing dependencies.

Example: a customer request involves an update to 3 tables in a database. For this update to be atomic, all 3 transaction updates should happen or nothing at all.

Contract Coupling

→ data transfer level: data exchange between microservices should agree on the data format being exchange (JSON schema, XML schema, RPC, etc).

More details on Managing Contracts section below.

Temporal Coupling

→ availability of the interacting microservices.

Example: microservice A requires microservice B to be available at a specific time to perform some functionality.

The Three Primal Dynamic-Coupling Forces

Every distributed system is shaped by three fundamental tensions:

Each of these forces is acting in their own spectrum axis which combine to form the 8 saga patterns covered later in Section 4.

The impacts of each of these driving forces will become apparent when we compare 8 different types of sagas based on the permutation of the options.

1. Communication

Synchronous vs. Asynchronous

Blocking vs. Non-blocking

Subtle difference between synchronous/asynchronous and blocking/non-blocking:

Examples

• Synchronous & Blocking (Standard): You call a function, and your code stops (blocks) and waits for the result before moving to the next line. Example: Reading a large file from disk; the program pauses until the file is fully loaded.

• Synchronous & Non-blocking: You start a task and immediately get control back (non-blocking), but you must manually check back (polling) until the task is complete. Example: Starting a download, then checking the progress bar every few seconds, but you still wait for that specific download to finish to proceed.

• Asynchronous & Blocking (Rare/Inefficient): The task runs in the background (asynchronous), but you still stop and wait for it to finish. Example: Starting a background task, but immediately sitting idle waiting for the “done” notification.

• Asynchronous & Non-blocking (Modern): You start a task and immediately move on to other work (non-blocking). When the task finishes, you are notified (asynchronous). Example: Sending an API request with a callback function; the main thread continues executing other code and handles the result only when the request completes.

Architectural Quantum

An architecture quantum establishes the scope for a set of architectural characteristics.

Characteristics of a quantum:

• Independent deployment
• High functional cohesion
• Low external-implementation static coupling
• Synchronous communication with other quanta

Synchronous calls create “dynamic quantum entanglement” — they couple the operational characteristics of separate services. A slow or unavailable downstream service degrades the entire call chain, i.e. the weakest characteristic of a service becomes the characteristic of the system.

**Your system is only as good as the least characteristics **

Asynchronous calls, on the other hand, retains the architecture quantum of individual services in a system.

Example:

In the above picture, the microservices on the right side form 1 architectural quanta because of the synchronous communication among the services.

When Portfolio Management System communicates with Trade Order Orchestrator, 2 things can happen:

1. If they communicate synchronously, they form into 1 architectural quantum => architectural characteristics drop to the lower level in the workflow.

1. If they communicate asynchronously, they stay separated as 2 architectural quanta => architectural characteristics are retained.

So how do we determine the communication type should be synchronous or asynchronous?

It depends on whether the service needs to wait for the response from another service. If so, then it’s synchronous.

Also for simplicity, default to synchronous communication. Synchronous → simpler

Trade-off Summary

Managing Contracts

When a service calls a method in another service, it’s a contract between the 2 services of what the request and response formats should be like.

Strict vs. Loose Contracts

Principle: Transfer values, not types. Value-based (loose) contracts decouple consumers from implementation changes.

Contract Fitness Functions

Consumer-Driven Contracts (CDCs) can automate contract verification.

The Pact framework (docs.pact.io) supports this for REST and event-driven architectures, with CI/CD integration.

Event Payload Design

Should an event carry the full data payload or just key identifiers?

Choose Key-Only Payload if scalability and performance are not the priority

Stamp coupling example: A customer profile returning 500 KB payloads at 2,000 req/s uses ~1,000,000 KB/s of bandwidth. Returning only required fields (~200 bytes) reduces this to ~400 KB/s — a 2,500× reduction.

Looser contracts create less brittle software architectures.

2. Coordination

Orchestration vs. Choreography

Orchestration

• generally one orchestrator per major workflow
• orchestrator owns state and communicates update points to services

Choreography

• services react to events
• no central controller
• the workflow emerges from the chain of events

Hybrids

• an orchestrated outer workflow can delegate to choreographed sub-workflows

Summary

3. Consistency

ACID Transactions

• Atomicity — all steps in a transaction either fully succeed or fully roll back together; there is no partial completion.

• Consistency — a transaction always moves the database from one valid state to another, never leaving data in a corrupt or rule-violating state.

• Isolation — concurrent transactions are invisible to each other until committed, so one transaction cannot see another’s in-progress changes.

• Durability — once a transaction is committed, the data is permanently saved and survives any subsequent system failure.

In a distributed context, standard ACID properties break down:

BASE Transactions

As an alternative, BASE (Basically Available, Soft state, Eventually consistent) is the natural fit for distributed, decoupled systems.

Eventual Consistency Patterns

Sample problem: Deleting a customer in one service must propagate to dependent services (wish list, preferences, etc.).

3 patterns for propagating state changes from the sample above:

1. Background Synchronisation → a background job reads across databases to sync state.
   ⚠️ Creates direct database coupling between services.
   

2. Event-Based Data Synchronisation → the originating service fires an event; consumers react.
   ✅ Decoupled. Standard Event-Driven Architecture pattern.
   

3. Workflow Event Pattern → a dedicated workflow processor mediates between the event producer and consumers, handling ordering and retries.
   

Compensating Updates

When a step fails partway through a distributed transaction, previously committed changes must be compensated (rolled back manually).

Fallacies of compensating updates:

• The compensating update itself may fail
• Side effects may have already occurred (e.g. an email sent, a charge processed)
• State management becomes complex

Mitigation (by state management): Marking data as WIP (Work-In-Progress) vs PLACED allows services to avoid querying data not yet in a finalisable state, reducing inconsistency windows.

When a system incorporates process for compensating updates, execution logs is crucial for traceability.

4. Transactional Sagas

8 Saga patterns can be formed by combining the 3 coupling forces:

Saga Descriptions

🗡️ Epic Saga — “A long-running, heroic story”

• Mimics a non-distributed transactional interaction
• Holistic transactional coordination increases coupling
• Easy to understand; difficult to implement

Use when: Each step must complete before the next starts; absolute transactionality matters more than responsiveness.

📖 Fantasy Fiction Saga — “A complex story that’s hard to believe in the end”

• Moving to async communication improves performance/responsiveness…
• …but introduces concurrency issues that may be worse than the original performance problems

Use when: A first attempt at improving an Epic Saga; responsiveness matters more than strict ordering.

🏡 Fairy Tale Saga — “An easy story with a pleasant ending”

• Sync + orchestrated = easiest to reason about
• The Orchestrated Saga in Chris Richardson’s Microservices Patterns book

Use when: Medium to complex workflows that don’t need extreme scale. Default choice for most situations.

⚡ Parallel Saga — “Multiple stories running at the same time”

• Orchestrator allows complex workflows with concurrency
• Highly attractive for complex workflows at high scale
• Difficult if ordering of updates matters

📞 Phone Tag Saga — “Like the game of phone tag”

• An unusual combination: atomic + choreography
• Adds scalability to a simple transactional workflow when the orchestrator becomes a bottleneck
• Not common in practice

😱 Horror Story Saga — “A nightmare”

• Attempts atomic workflows without a coordinator, with concurrency on top
• Workflow, error handling, boundary conditions, and transactionality are spread across domain services
• Middling performance coupled with impossible-to-reproduce errors
• Actually an anti-pattern

⚠️ Not uncommon in practice. Usually a well-intentioned but flawed attempt to achieve high performance with atomicity.

⏳ Time Travel Saga — “A problem that moves atomically through time”

• No orchestrator makes complex workflows difficult
• Best for pipeline problems (chain-of-responsibility, pipes-and-filters) with staging or additive workflows
• Works best when synchronous communication is acceptable

📚 Anthology Saga — “A loosely associated group of short stories”

• The Choreographed Saga in Chris Richardson’s Microservices Patterns book
• Polar opposite of the Epic Saga
• Best for non-transactional pipes-and-filters architecture styles
• Highly scalable due to lack of coupling - the least coupled option

Quantitative Trade-off Summary

Mixing the properties of the 3 axes of dynamic coupling forces, Consistency choice has the greatest impact on saga quality, followed by Coordination style then Communication mode.

Consistency → Coordination → Communication

Saga Profiles

Below is the 8 transactional sagas score cards:

The table above gives a simplified guidance on the system architecture we should have to achieve the characteristic priorities implied.

For example, to have a distributed system with low response latency, the table shows below:

Now the option is just either we want orchestrated or choreographed system. If scalability is the next priority, then anthology saga is the pattern we should follow. If simplicity is, parallel saga is the pattern.

Also from the table we can see that what drives an orchestration system down on scalability and responsiveness is not the orchestration itself but it’s the atomic transactions. Once we tweak the transactions to be eventual consistent, we should expect improvements in responsiveness and scalability of the system.

Transactional Sharding

For very high-volume scenarios, domain sharding distributes load across multiple Saga instances for better performance/responsiveness.

Example: a concert ticket sale spike can be handled by sharding by seat section or venue zone, avoiding a single transaction bottleneck.

Domain sharding maps naturally onto microservices: services can be sharded by geography or specialisation, allowing concurrent saga instances without contention.

Key Principles Summary

This document summarizes the most important updates relevant for developers.

1. Language Features

Primitive Types in Pattern Matching (Preview)

Pattern matching has been expanded to support primitive types in switch and other pattern contexts.

Example:

switch (value) {
    case int i -> System.out.println("Integer: " + i);
    case double d -> System.out.println("Double: " + d);
}

Benefits:

• More consistent pattern matching
• Simplifies conditional logic
• Better support for performance‑sensitive code

Module Import Declarations

Java now allows importing all exported packages from a module in a single statement.

import module java.sql;

Advantages:

• Reduces boilerplate imports
• Makes modular libraries easier to use
• Simplifies dependency usage

Compact Source Files and Instance Main Methods

This feature removes much of the boilerplate needed for small programs.

Traditional Java:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

Simplified version:

void main() {
    System.out.println("Hello World");
}

2. Concurrency Improvements

Structured Concurrency

Structured concurrency simplifies working with groups of concurrent tasks.

Concept example:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<String> user = scope.fork(() -> findUser());
    Future<Integer> order = scope.fork(() -> fetchOrder());

    scope.join();
}

Benefits:

• Simplified thread coordination
• Improved error handling
• Better cancellation support

Scoped Values

Scoped values provide a safe alternative to ThreadLocal variables.

Key characteristics:

• Immutable data sharing
• Lower memory overhead
• Better integration with virtual threads

Example:

ScopedValue<String> USER = ScopedValue.newInstance();

3. Performance Improvements

Compact Object Headers

Java 25 introduces smaller object headers on 64‑bit architectures.

Benefits:

• Reduced memory footprint
• Improved cache efficiency
• Higher application density

Vector API

The Vector API allows developers to write vectorized computations that map to modern CPU vector instructions.

Use cases:

• machine learning
• financial simulations
• scientific computing
• AI inference workloads

4. Security Enhancements

PEM Encoding API

Java introduces a built-in API for reading and writing cryptographic objects in PEM format.

Supported items include:

• cryptographic keys
• certificates
• certificate revocation lists

Key Derivation Function API

Provides standard APIs for deriving secure cryptographic keys from shared secrets.

Use cases:

• encryption systems
• password-based key generation
• modern cryptographic protocols

5. Observability Improvements

Java Flight Recorder Enhancements

Java Flight Recorder receives improvements including:

• CPU-time profiling
• cooperative stack sampling
• detailed method timing

These tools improve diagnostics for performance bottlenecks in production systems.

6. Platform Changes

Removal of 32‑bit x86 Support

Java 25 removes support for legacy 32‑bit x86 systems, focusing exclusively on modern 64‑bit architectures.

Benefits:

• simplified JVM maintenance
• better performance optimizations
• reduced platform complexity

Conclusion

Java 25 continues improving the platform with stronger support for:

• concurrency
• performance optimization
• cryptography
• developer productivity
• runtime observability

These improvements help keep Java competitive for enterprise systems, cloud workloads, and high-performance computing.

This decoupling brings versatility: the same domain logic can interact with different clients and persistence mechanisms without modification.

Why Hexagonal Architecture?

In a traditional layered architecture, the domain model often leaks dependencies on persistence or UI layers. For example, switching from a REST API to a CLI or from a relational database to an in-memory store can require changes to the business code.

Hexagonal architecture solves this by:

• Defining input ports: how external actors (users, APIs, scheduled jobs) communicate with the application.
• Defining output ports: how the application communicates with external systems (databases, queues, external services).
• Keeping the core domain pure: the business logic depends only on ports, not on specific technologies.

Example Scenario

Let’s implement a simple Task Management system with:

• 2 Input Ports:

  1. A REST API (adapter).
  2. A Command-Line Interface (adapter).

• 2 Output Ports:

  1. A persistence store (adapter for in-memory or database).
  2. A notification service (adapter for console logging or email).

The core domain logic only knows about ports, not about HTTP, JDBC, or logging.

Step 1: Define the Domain Model

public class Task {
    private final String id;
    private final String description;
    private boolean completed;

    public Task(String id, String description) {
        this.id = id;
        this.description = description;
        this.completed = false;
    }

    public void markCompleted() {
        this.completed = true;
    }

    public boolean isCompleted() {
        return completed;
    }

    public String getId() {
        return id;
    }

    public String getDescription() {
        return description;
    }
}

Step 2: Define Ports

Input Ports (driving the application)

public interface TaskUseCase {
    Task createTask(String description);
    void completeTask(String taskId);
}

Output Ports (driven by the application)

public interface TaskRepository {
    Task save(Task task);
    Task findById(String id);
}

public interface NotificationService {
    void notify(String message);
}

Step 3: Core Application Logic

import java.util.UUID;

public class TaskService implements TaskUseCase {

    private final TaskRepository taskRepository;
    private final NotificationService notificationService;

    public TaskService(TaskRepository taskRepository, NotificationService notificationService) {
        this.taskRepository = taskRepository;
        this.notificationService = notificationService;
    }

    @Override
    public Task createTask(String description) {
        Task task = new Task(UUID.randomUUID().toString(), description);
        taskRepository.save(task);
        notificationService.notify("Task created: " + task.getDescription());
        return task;
    }

    @Override
    public void completeTask(String taskId) {
        Task task = taskRepository.findById(taskId);
        task.markCompleted();
        taskRepository.save(task);
        notificationService.notify("Task completed: " + task.getDescription());
    }
}

Notice that TaskService doesn’t know if persistence is a database or in-memory, or if notifications go to email, SMS, or console.

Step 4: Implement Adapters

Output Adapters

In-memory persistence:

import java.util.HashMap;
import java.util.Map;

public class InMemoryTaskRepository implements TaskRepository {
    private final Map<String, Task> store = new HashMap<>();

    @Override
    public Task save(Task task) {
        store.put(task.getId(), task);
        return task;
    }

    @Override
    public Task findById(String id) {
        return store.get(id);
    }
}

Console notification:

public class ConsoleNotificationService implements NotificationService {
    @Override
    public void notify(String message) {
        System.out.println("NOTIFICATION: " + message);
    }
}

Input Adapters

Command-line interface:

public class CliAdapter {
    private final TaskUseCase taskUseCase;

    public CliAdapter(TaskUseCase taskUseCase) {
        this.taskUseCase = taskUseCase;
    }

    public void run() {
        Task task = taskUseCase.createTask("Write hexagonal architecture article");
        taskUseCase.completeTask(task.getId());
    }
}

REST controller (example using Spring Web):

import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/tasks")
public class RestAdapter {

    private final TaskUseCase taskUseCase;

    public RestAdapter(TaskUseCase taskUseCase) {
        this.taskUseCase = taskUseCase;
    }

    @PostMapping
    public Task create(@RequestParam String description) {
        return taskUseCase.createTask(description);
    }

    @PostMapping("/{id}/complete")
    public void complete(@PathVariable String id) {
        taskUseCase.completeTask(id);
    }
}

Step 5: Wiring It Together

public class Application {
    public static void main(String[] args) {
        TaskRepository repository = new InMemoryTaskRepository();
        NotificationService notification = new ConsoleNotificationService();
        TaskUseCase taskService = new TaskService(repository, notification);

        // CLI example
        CliAdapter cli = new CliAdapter(taskService);
        cli.run();

        // For REST, Spring Boot would autowire `taskService` into `RestAdapter`
    }
}

Key Benefits

1. Versatility: The same TaskService can serve a CLI, REST API, or even a message consumer without modification.
2. Replaceability: Swap the InMemoryTaskRepository with a JdbcTaskRepository without touching the core logic.
3. Testability: The core can be tested with mock ports, no need for real databases or frameworks.
4. Future-proofing: Adding new adapters (e.g., GraphQL, Kafka, Email) requires no change in business logic.

Conclusion

This simple implementation illustrates the power of Hexagonal Architecture in Java. Even with minimal domain logic, you can see how ports and adapters provide flexibility and clarity. The business core is free from infrastructure concerns, making the application more maintainable, extensible, and adaptable to future changes.

Resources

1. Hexagonal architecture, article by Alistair Cockburn
2. Github code here
3. More sample - Github code here as per article by happycoders.eu

In this article, we will dive into the world of Helidon MP and create a Helidon MP based project!

What Is Helidon MP?

Helidon MP is the MicroProfile edition of Helidon. While Helidon SE provides a functional, low-level API for microservices, Helidon MP adds a full stack of enterprise-ready features:

• JAX-RS for building RESTful APIs

• CDI for dependency injection

• JSON-P/B for JSON processing

• Health checks, metrics, and tracing for observability

• Fault tolerance and configuration via MicroProfile APIs

Unlike traditional Java EE servers, Helidon MP is lightweight, fast, and cloud-native. It doesn’t require a full application server and runs directly on the JVM or as a GraalVM native image.

Why Choose Helidon MP?

• Standards-Based: Implementing MicroProfile ensures portability across compliant frameworks.

• Cloud-Ready: Out-of-the-box support for Docker, Kubernetes, Prometheus, and OpenTelemetry.

• High Performance: Minimal overhead and fast startup times make it ideal for microservices and serverless deployments.

• Modern Java Features: Supports Java 21 features, including virtual threads, enabling simple, efficient concurrency.

Getting Started

Using Helidon Project Generator

Head to helidon’s starter page for a guided starter project generator.

Simply click download to access your project.

Using Maven

A minimal Helidon MP project can be created using Maven:

mvn -U archetype:generate -DinteractiveMode=false \
    -DarchetypeGroupId=io.helidon.archetypes \
    -DarchetypeArtifactId=helidon-quickstart-mp \
    -DarchetypeVersion=4.1.0 \
    -DgroupId=com.javarchitect.helidon \
    -DartifactId=helidon-mp-example \
    -Dpackage=com.javarchitect.helidon

From there, you can define JAX-RS endpoints, add MicroProfile health checks, and run your microservice in a few simple steps.

Conclusion

Helidon MP is perfect for developers who want enterprise Java microservices that are lightweight, standards-compliant, and cloud-ready. By leveraging MicroProfile and Helidon’s high-performance runtime, you get the best of both worlds: modern microservices architecture without the complexity of a traditional Java EE server.

For more information, visit the official Helidon website.

In this article, we’ll cut through the noise with clear, practical guidance: which structure to use, when to use it, and why. From performance considerations to concurrency safety, this guide will help you make the smart choice every time.

Let’s go through the Java Collections Framework (and a few extras in java.util.concurrent), but framed from a practical performance + concurrency perspective.

📚 Core Java Data Structures and When to Use Them

List Implementations

ArrayList
✅ Best for: Random access, iteration.
❌ Avoid when: Many insertions/deletions in the middle.
Perf: Backed by an array, so get(int) and set(int) are O(1), but inserts/removes (except at end) are O(n).

LinkedList
✅ Best for: Frequent inserts/removes at both ends (addFirst, addLast).
❌ Poor for: Random access (get(i) is O(n)).
Perf: Doubly linked nodes, predictable memory usage but slower iteration (cache-unfriendly).

CopyOnWriteArrayList (concurrent)
✅ Best for: Mostly-read, rarely-write scenarios in multithreaded contexts (e.g., event listeners).
Perf: Writes copy the entire array → expensive, but reads are lock-free and very fast.

Set Implementations

HashSet
✅ Best for: Fast lookup and uniqueness.
Perf: Backed by HashMap, average O(1) add/remove/contains.

LinkedHashSet
✅ Best for: Fast lookup + predictable iteration order (insertion order).
Perf: Slightly slower than HashSet due to linked list overhead.

TreeSet
✅ Best for: Sorted unique data, range queries.
Perf: Backed by a Red-Black tree. All ops are O(log n).

ConcurrentSkipListSet (concurrent)
✅ Best for: Thread-safe sorted set with lock-free reads.
Perf: Based on skip lists, good scalability under contention.

Map Implementations

HashMap
✅ Best for: General key/value storage with fast lookup.
Perf: Average O(1) for get/put. Not thread-safe.

LinkedHashMap
✅ Best for: Fast lookup + predictable iteration order.
Special: Supports access-order iteration → ideal for LRU caches.

TreeMap
✅ Best for: Sorted map with range queries.
Perf: O(log n) for get/put. Higher overhead than HashMap.

ConcurrentHashMap (concurrent)
✅ Best for: High-concurrency map with frequent reads/writes.
Perf: Lock-striping, non-blocking reads, scalable under contention.

WeakHashMap
✅ Best for: Caches where keys should be GC-collected when no longer referenced.
Perf: Slight overhead due to reference queues.

Queue & Deque Implementations

ArrayDeque
✅ Best for: Fast stack/queue (double-ended).
Perf: Much faster than LinkedList for stack/queue operations.

PriorityQueue
✅ Best for: Always retrieving the “smallest” or “largest” element.
Perf: Backed by a binary heap, O(log n) insertion/removal.

ConcurrentLinkedQueue (concurrent)
✅ Best for: Lock-free FIFO in multi-threaded environments.
Perf: Scales well with many producers/consumers.

BlockingQueue family (e.g., LinkedBlockingQueue, ArrayBlockingQueue)
✅ Best for: Producer/consumer designs with thread blocking.
Perf: Choice depends on bounded/unbounded and fairness requirements.

ConcurrentLinkedDeque (concurrent)
✅ Best for: Lock-free double-ended queue, suitable for work-stealing.

Specialized Collections

EnumSet / EnumMap
✅ Best for: High-performance collections keyed by enums.
Perf: Backed by bit vectors, extremely fast and memory efficient.

IdentityHashMap
✅ Best for: When key identity (==) matters instead of equality (equals()).
Perf: Rare use cases like serialization, object graph traversal.

🚀 Rules of Thumb

High lookup speed? → HashMap / HashSet.
Need ordering? → LinkedHashMap / TreeSet / TreeMap.
Sorted & concurrent? → ConcurrentSkipListMap / ConcurrentSkipListSet.
Producer/consumer threads? → BlockingQueue.
Read-heavy, write-rarely? → CopyOnWriteArrayList / CopyOnWriteArraySet.
Event-driven caching? → LinkedHashMap with access-order eviction.
GC-aware caching? → WeakHashMap.

⚡Performance tip:

In single-threaded contexts, prefer non-concurrent versions — they’re much faster. For concurrency, always start with ConcurrentHashMap or ConcurrentLinkedQueue before rolling your own synchronization.

Flow chart based on the description above:

Sample code: Github repo
Mermaid chart code: here