Atmora Tech

Engineering

Integration fails at 3am.
Design for that.

Point-to-point connections are cheap to build and expensive to own; by the fortieth one, nobody can say what breaks if a system goes down. We design integration estates around explicit contracts, idempotent consumers and replayable event logs.

Overview

Contracts, idempotency and replay — the unglamorous parts that keep 40 systems in step.

An integration estate is a distributed system whether or not anyone designed it as one. The failure modes are the ones distributed systems always have: duplicate delivery, out-of-order events, partial writes, and a downstream that was unavailable for eleven minutes without telling anyone. Connectivity is the easy half.

We treat interfaces as products. Each has an owner, a versioned schema in a registry, a documented compatibility policy, and a consumer-driven contract test that runs in the producer's pipeline. Producers cannot ship a breaking change without a failing build, which is the only enforcement mechanism that survives a busy quarter.

The runtime choices follow from the guarantees you need. Synchronous REST or gRPC where a caller must know the answer now; durable messaging where it must not lose the request; change data capture where a system has no usable API and never will. We will tell you which of your integrations does not need an event bus.

312 to 47
point-to-point interfaces reduced to governed contracts at Corvus Logistics
0.03%
message replay rate after idempotency keys were added estate-wide
4.2 days
average partner EDI onboarding, down from six weeks at Orbit Supply

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • API design and contract governance

    OpenAPI and AsyncAPI specifications held in a registry, with compatibility rules enforced in CI. Consumer-driven contract tests run in the producer pipeline, so a breaking change fails a build rather than a customer.

  • Event streaming and messaging backbones

    Kafka, RabbitMQ or cloud-native brokers configured for the delivery guarantee the use case actually requires, with partition keys chosen for ordering behaviour rather than for throughput vanity metrics.

  • iPaaS and ESB migration

    MuleSoft, Boomi, TIBCO and BizTalk estates audited flow by flow, then split into what stays on the platform, what moves to code, and what turns out to be duplicated three times over.

  • Idempotency, retries and replay

    Every consumer gets a deduplication key, a bounded retry policy and a dead-letter path that a human can drain. Replay from the log is a supported operation, not a heroic recovery.

  • B2B and EDI connectivity

    EDIFACT, X12, AS2 and SFTP partner onboarding with validation at the edge, so a malformed partner file is rejected with a readable error instead of poisoning a downstream queue.

  • Integration observability

    Correlation IDs threaded through every hop, with dashboards showing consumer lag, dead-letter depth and latency across a whole business transaction rather than per individual service.

Deliverables

What you get

  • Interface catalogue with owners, schemas and compatibility policies
  • Schema registry with CI-enforced compatibility checks
  • Consumer-driven contract test suites wired into producer pipelines
  • Reference integration patterns with working code templates
  • Dead-letter handling runbooks and replay tooling
  • Per-transaction observability dashboards and alert thresholds

Stack

What we build it with

  • Apache Kafka
  • Confluent Schema Registry
  • RabbitMQ
  • Debezium
  • Kong Gateway
  • MuleSoft Anypoint
  • Apache Camel
  • gRPC
  • OpenAPI
  • AsyncAPI
  • Pact
  • OpenTelemetry

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Estate audit

    Every interface catalogued with its protocol, volume, owner and failure history, including the shell scripts on a server nobody has logged into since 2019.

  2. Contract definition

    Schemas, versioning rules and compatibility policies are agreed with producing and consuming teams, then encoded in a registry that CI actually checks.

  3. Backbone build

    The messaging or API layer is provisioned with the delivery guarantees, retention and access controls the audited traffic profile requires, not the defaults.

  4. Migration by flow

    Flows move one at a time, running in parallel against the old path with output comparison, so a rollback is switching a route rather than restoring a platform.

  5. Operational handover

    Runbooks, dashboards and replay tooling handed to the team that will be paged, with a joint on-call period before we step back.

When this is the wrong engagement

If you run fewer than about a dozen integrations and they change rarely, a governed integration estate is overhead you will pay for and never use.

FAQ

Questions we get asked

Do we need an event-driven architecture?

Probably for some of it, not all of it. Events suit workflows where the producer does not care who consumes them and eventual consistency is acceptable; a credit check that blocks a checkout is not one of those. We size the messaging layer to the flows that genuinely need it.

We already own MuleSoft. Is that wasted?

No. Licensed platforms earn their keep on partner connectivity, protocol mediation and flows your teams do not want to maintain in code. What we usually change is the proportion: high-volume internal traffic moves to code and a broker, while the platform keeps the work it is good at.

How do you stop teams from breaking each other's interfaces?

Tooling, not policy documents. Schemas live in a registry with a compatibility rule, contract tests supplied by consumers run inside the producer's pipeline, and an incompatible change turns the build red before review. Governance that depends on people remembering does not hold.

What about systems with no API at all?

Change data capture off the database log, or a file-based contract with validation at the edge. Both are legitimate, both need explicit ownership of the schema, and both should sit in the same catalogue as your REST interfaces so nobody treats them as invisible plumbing.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project