Integration Patterns 2026: Query Patterns (Consistency vs Availability)

<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_3103"></div> <p class="wp-block-paragraph">I started the year using Gemini Pro to take our integration patterns and covert them into “playing card” style pattern library so that we can print and play! The content is mine, I used AI to generate the images with still a few issues with image text – oh well, maybe something to refine later in 2026 or next year. In this post we explore “Read-side” or Query based integration patterns where performance and correctness are key design decisions. These patterns separate “freshness” from “availability” by design and lean heavily on C.A.P theorem</p> <h2 class="wp-block-heading">Included patterns</h2> <ul><li><a href="#qp-1">QP-1 — Real-time Consistent Read (Master)</a></li><li><a href="#qp-2">QP-2 — Real-time Cached Read (Operational Data Store)</a></li><li><a href="#qp-3">QP-3 — Real-time Cached Bulk Read</a></li></ul> <h2 class="wp-block-heading" id="qp-1">QP-1: Real-time Consistent Read (Master)</h2> <figure class="wp-block-image size-large"><img src="https://alok-mishra.com/wp-content/uploads/2026/01/qp-1_real-time_consistent_read_master.png?w=1024&quot; alt="" class="wp-image-3160" /></figure> <p class="wp-block-paragraph">Synchronous read that returns the latest committed state from the system-of-record (master).</p> <h3 class="wp-block-heading">When to use</h3> <ul><li>Client requires latest state (strong consistency).</li><li>Throughput is low to moderate and latency can be higher.</li><li>Fine-grained reads (by ID, small payloads).</li></ul> <h3 class="wp-block-heading">Pros</h3> <ul><li>Always freshest data.</li><li>Simple client semantics (no staleness handling).</li></ul> <h3 class="wp-block-heading">Cons</h3> <ul><li>Lower availability under partitions; can be slower.</li><li>Can overload master if used for high-volume read traffic.</li></ul> <h3 class="wp-block-heading">PlantUML</h3> <pre class="wp-block-code"><code>@startuml title Real-time Consistent Read (Master) actor "Client" as Client participant "API/BFF" as API_BFF participant "Master System" as Master_System Client -> API_BFF: GET /resource/{id} API_BFF -> Master_System: Read latest state Master_System -> API_BFF: 200 OK (fresh data) API_BFF -> Client: 200 OK (fresh data) @enduml</code></pre> <h2 class="wp-block-heading" id="qp-2">QP-2: Real-time Cached Read (Operational Data Store)</h2> <figure class="wp-block-image size-large"><img src="https://alok-mishra.com/wp-content/uploads/2026/01/qp-2_real-time_cached_read_operational_data_store.png?w=1024&quot; alt="" class="wp-image-3159" /></figure> <p class="wp-block-paragraph">Synchronous read served from an operational cache/ODS refreshed from master.</p> <h3 class="wp-block-heading">When to use</h3> <ul><li>Client can tolerate slightly stale data (bounded staleness).</li><li>High read throughput and low latency are required.</li><li>Fine-grained reads.</li></ul> <h3 class="wp-block-heading">Pros</h3> <ul><li>High throughput and low latency.</li><li>Protects the master from read load.</li><li>Improves availability.</li></ul> <h3 class="wp-block-heading">Cons</h3> <ul><li>Stale reads possible.</li><li>Cache invalidation/refresh complexity.</li><li>Requires cache warm-up and consistency monitoring.</li></ul> <h3 class="wp-block-heading">PlantUML</h3> <pre class="wp-block-code"><code>@startuml title Real-time Cached Read (Operational Data Store) actor "Client" as Client participant "API/BFF" as API_BFF participant "Cache/ODS" as Cache_ODS participant "Master System" as Master_System Client -> API_BFF: GET /resource/{id} API_BFF -> Cache_ODS: Lookup cached state Cache_ODS -> API_BFF: 200 OK (cached state) API_BFF -> Client: 200 OK (cached state) @enduml</code></pre> <h2 class="wp-block-heading" id="qp-3">QP-3: Real-time Cached Bulk Read</h2> <figure class="wp-block-image size-large"><img src="https://alok-mishra.com/wp-content/uploads/2026/01/qp-3_real-time_cached_bulk_read.png?w=1024&quot; alt="" class="wp-image-3158" /></figure> <p class="wp-block-paragraph">Synchronous read for large subsets using indexed cache/ODS to serve bulk queries quickly.</p> <h3 class="wp-block-heading">When to use</h3> <ul><li>Client needs a large subset (search/filters) with low latency.</li><li>Master cannot support complex/high-volume bulk queries.</li><li>Staleness is acceptable.</li></ul> <h3 class="wp-block-heading">Pros</h3> <ul><li>Fast bulk queries.</li><li>Offloads master query complexity.</li><li>Enables richer query models (search/index).</li></ul> <h3 class="wp-block-heading">Cons</h3> <ul><li>Staleness and sync lag.</li><li>Index/ODS build and operational overhead.</li><li>Risk of cache used as primary source unintentionally.</li></ul> <h3 class="wp-block-heading">PlantUML</h3> <pre class="wp-block-code"><code>@startuml title Real-time Cached Bulk Read actor "Client" as Client participant "API/BFF" as API_BFF participant "Search Index/ODS" as Search_Index_ODS participant "Master System" as Master_System Client -> API_BFF: GET /resources?filter=... API_BFF -> Search_Index_ODS: Query indexed dataset Search_Index_ODS -> API_BFF: 200 OK (result set) API_BFF -> Client: 200 OK (result set) @enduml</code></pre> <h2 class="wp-block-heading">Summary</h2> <p class="wp-block-paragraph">We looked at simple query patterns which can be composed into more complex end to end solutions for back and forth query chains. Before implementing though we must consider the following:</p> <ul class="wp-block-list"> <li>Define the contract first (schema, idempotency key, ordering expectations)</li> <li>Make retries safe (idempotent handlers, dedupe, at-least-once assumptions)</li> <li>Prefer explicit staleness windows over implicit “eventual consistency” depending on usecase and business needs</li> <li>Instrument job state and failure modes (metrics + searchable logs) because operability is a key ility! </li> </ul> <p class="wp-block-paragraph">Let me know your most used pattern – do you keep it simple generally? What is the most complex read/query ask and why?</p> <p class="wp-block-paragraph">Also, how would we use simple query patterns to get a large body of data or large collection iteratively? Tell me your answer</p>

@startuml
title Real-time Consistent Read (Master)
actor "Client" as Client
participant "API/BFF" as API_BFF
participant "Master System" as Master_System
Client -> API_BFF: GET /resource/{id}
API_BFF -> Master_System: Read latest state
Master_System -> API_BFF: 200 OK (fresh data)
API_BFF -> Client: 200 OK (fresh data)
@enduml

@startuml
title Real-time Cached Read (Operational Data Store)
actor "Client" as Client
participant "API/BFF" as API_BFF
participant "Cache/ODS" as Cache_ODS
participant "Master System" as Master_System
Client -> API_BFF: GET /resource/{id}
API_BFF -> Cache_ODS: Lookup cached state
Cache_ODS -> API_BFF: 200 OK (cached state)
API_BFF -> Client: 200 OK (cached state)
@enduml

@startuml
title Real-time Cached Bulk Read
actor "Client" as Client
participant "API/BFF" as API_BFF
participant "Search Index/ODS" as Search_Index_ODS
participant "Master System" as Master_System
Client -> API_BFF: GET /resources?filter=...
API_BFF -> Search_Index_ODS: Query indexed dataset
Search_Index_ODS -> API_BFF: 200 OK (result set)
API_BFF -> Client: 200 OK (result set)
@enduml