Skip to main content

CQRS Proxy

Context​

The system is split into multiple microservices with corresponding APIs. There is at least one 3rd party application (e.g. an external API, a CMS, ...) or a legacy system during a migration that shall be integrated into the system.

Problem​

  • In a migration scenario, a big bang integration or parallel adoption is too much risk
  • Integrating 3rd party applications or the legacy system leads to an inconsistent integration landscape (e.g. different communication protocol)
  • The integrated 3rd party application or legacy system does not live up to the availability guarantees required for a microservice-based system
  • There is a large discrepancy of what data is written to the 3rd party or legacy system and what is read

Solution​

Wrap the 3rd party or legacy system with a CQRS proxy microservice. CQRS ("Command and Query Responsibility Segregation") is a design pattern that allows optimized read models on the data while perserving an optimized write model. This design pattern can be applied in a proxy microservice if the wrapped system is viewed as the underlying data store. Wile the write model is predetermined by the wrapped system, there can be multiple optimized read models within the proxy microservice.

This technique is a specialization of the data replication proxy (and transitively, of the proxy microservice) technique.

Maturity​

More data is required (only 2 sources).

Sources of Evidence​

Note: As this technique is a specialization of the data replication proxy (and transitively, of the proxy microservice) technique, we also used their sources to formulate this technique.

Interview D:

  • Context: build a facade for an external system
  • CQRS pattern:
    • write commands for the change,
    • read state information instead of doing real queries
    • questions to be asked: what kind of cache do I need, how big, how up-to-date?

Interview F:

  • Context: building a facade for a legacy system
  • need for a cache layer (independent if facade or integration service)
    • cache = intermediate data storage - not important if in-memory or on disk
    • leads to a decoupling
  • their approach is CQRS like
    • queue for changes
    • different caches for different kinds of data and requests in the corresponding schemas that could be requested
    • below: they implemented adapters => kind of an SPI
      • generic part to the microservice site, adapters to external site
      • throwing CSV files around
      • accessing FTP servers
      • accessing database tables
      • remote function calls