All work
Professional ExperienceReal estate lending services

Accept, route, then adapt: one message path for many vendor networks

Every vendor message is kept exactly as sent until it reaches the system that needs it, and translated only there.

Context

A title and property valuation services company supporting lenders, for example confirming a property’s value before a bank funds a loan. Several lines of business each worked with their own network of vendors, and each had its own operational needs. The work came early in the company’s move to the cloud. It was a team effort.

The problem

The existing system was heavy and slow. Messages passed through layer after layer of translation on their way through, even though the only translation that mattered was the one at the destination. Every part had to understand every other part, so each new vendor or format meant changes throughout, and the system kept far more data than the work needed. Overnight messages took hours of manual work each morning to push through.

Constraints

  • Accepting a message could never make a sender wait on anything downstream, and nothing a vendor sent could be lost.
  • The same message could arrive more than once and had to take effect only once.
  • Each vendor could send its own message format.
  • The rules for each line of business belonged to the systems that line of business owned.
  • Requesters needed to know their information had arrived, and every later message had to be matched back to it.

Approach

The new design kept each message exactly as it arrived until the point of delivery, and gave each part one job. The intake knew what to accept. Routing knew where each message needed to go. Each connection knew one provider’s format, and translated the message only there, into a form the receiving system understood.

Agreed contracts between the parts did most of the work, so no part needed to know how the others worked. Messages were saved the moment they arrived, so senders got an answer straight away and everything else happened in the background.

Each connection also sent a receipt back to the requester and matched later messages to the original. The system kept only what it needed to route and match messages, not a copy of each business system’s data.

Key engineering decisions

  • Translate once, at the destination

    Messages stayed exactly as sent until they reached the connection for their destination, so translation happened once, where it was needed, instead of at every layer.

  • One job per part

    Intake, routing, and each provider’s connection each did one thing. Supporting a new vendor or format meant adding a connection, not changing everything else.

  • Accept immediately, store first

    Accepting a message only saved it and replied, so senders never waited on anything downstream, and a step that failed later could pick the message up again from the stored copy.

  • Pause delivery, never intake

    Outgoing delivery could be switched off while messages kept arriving and being saved. A fix was deployed, delivery switched back on, and the held messages flowed through, so problems could be fixed during the working day.

Result

A handful of services replaced the layered system, and the mornings spent pushing overnight messages through by hand. Processing became consistent enough to release updates daily, with fixes deployed during the day while messages kept arriving. Supporting another vendor format or line of business meant adding a connection, not reworking the whole system.

Technologies

  • Azure Service Bus
  • Azure Blob Storage
  • Azure Service Fabric
  • Inbox pattern
  • Message adapters

Related expertise

Working through something similar?

Tell us what you have in mind. We’ll work out the next step together.

Start a Conversation