Reduce Platform Risks Using Proxy Pattern

June 8, 2016

There are a number of risks when your platform integrates with an external service / dependency. For instance, here are a few risks and things that can go wrong:

  1. Doesn’t respond at all. Just blocks indefinitely eating client-side resources.
  2. Responds progressively slower – i.e. response time degradation.
  3. Needs retry logic to deal with transient failures (Note: obviously care needs to be taken if the call isn’t idempotent!)
  4. Responds with an unexpected return code – e.g. internal server error or service unavailable error, etc.
  5. Gets overwhelmed by the rate of requests being set to it. Ideally, it should have protection against this but what if it is not entirely in your team’s control.
  6. Becomes unavailable throwing runtime exceptions forcing undesirable side-effects on the caller rather than failing fast.

Michael Nygard in his book Release It! talks about leveraging circuit breakers to deal with integration risks. Broadening that idea a bit, we could combine circuit breakers and mediation into a more generic Integration Proxy component. This proxy could implement a number of common concerns when working with external APIs:

  • Capture response time and route metrics to an analytics agent asynchronously
  • Monitor stale connections and automatically reset them if possible
  • Host the circuit breaker with associated logic to toggle based on service health
  • Provide “fallback” responses if circuit breaker kicks in to disable integration point.
  • Host sleep / retry invocation logic using parameters like interval and max attempts
  • Automatically flush pending / bufferred messages when service is available again.
  • Enable request and response capture – specially for debugging production issues.
Advertisements

Role of Systematic Reuse in Enterprise Integration

January 7, 2012

Systematic reuse in the context of enterprise integration provides several benefits:

  • allows the team to evolve consistent set of data interfaces across integration efforts – if multiple systems need to integrate with yours, can you define a generic data model for your domain-specific concepts? This could be file layout(s), service interface schemas, or platform specific APIs
  • enables common interfaces for domain specific services and business processes
  • integration points often need cross-cutting concerns such as logging, transaction management, exception handling, etc. that can be reused
  • reusable utilities can help with support and testing tools – for instance,  reply failed messages, drain message queues/topics, generate high volume test data, etc.

Question is – are your teams taking advantage of integration points? or is each integration point implementing identical or similar functionality in an inconsistent fashion?


%d bloggers like this: