𝗦𝗵𝗮𝗿𝗲𝗱 𝗟𝗶𝗯𝗿𝗮𝗿𝘆 𝗖𝗵𝗮𝗼𝘀 — 𝗗𝗶𝗻𝗴 𝗗𝗼𝗻𝗴! 🔔

Imagine an internal shared library that handles RabbitMQ connections, queues, and consumers for ~50 microservices running in Kubernetes.

Now RabbitMQ needs to move from 3.13.7 → 4.0.4 for ongoing support and newer queueing models such as quorum queues.

But there’s a problem.

RabbitMQ 4.x introduces a breaking change in queue declarations, which impacts the existing shared library — and potentially all 50 services.

So the real question becomes:

How do we manage shared dependencies across dozens of microservices without turning every upgrade into a coordinated fire drill?

𝗗𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 ❌

Upgrade RabbitMQ ↓ Upgrade RabbitMQ.Client ↓ Upgrade shared library ↓ Force 50 microservices to upgrade ↓ Everything breaks simultaneously 😆

Two 𝗕𝗲𝘁𝘁𝗲𝗿 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵𝗲𝘀 😎

Don’t make all 50 microservies understand RabbitMQ 4.0.4 at once. Upgrade the shared RabbitMQ library first, make it backward-compatible at the application API level, then roll the library version through the services in controlled batches.

Two approaches coming to my mind 𝟭. 𝗖𝗣𝗠 + 𝗚𝗶𝘁 𝗦𝘂𝗯𝗺𝗼𝗱𝘂𝗹𝗲 (How do we control which version of our shared library each service consumes?) Nuget Central Package Management (CPM) is useful to centrally controlling Nuget versions across projects, while Git submodules can pin each microservice repository to a specific version/commit of the shared library. Microsoft specifically supports centralized package versions through Directory.Packages.props. CPM manages NuGet dependency versions. It does not solve the compatibility problem between. That’s where the shared library API design + Git versioning/submodules come into play.

Instead of exposing RabbitMQ declaration details to every service, make the shared library own the RabbitMQ-specific behavior. This is the critical abstraction. Make the shared library backward compatible. Now bring in Git Submodule for the shared library. The submodule let you point to a specific commit. Order Service can now point to commit abc123 while payment service can have def456.

𝗛𝗼𝘄𝗲𝘃𝗲𝗿, 𝗶𝗳 𝘁𝗵𝗲 𝘀𝗵𝗮𝗿𝗲𝗱 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝗶𝘀 𝗮 𝗻𝗼𝗿𝗺𝗮𝗹 𝗡𝘂𝗚𝗲𝘁 𝗹𝗶𝗯𝗿𝗮𝗿𝘆, 𝗜 𝘄𝗼𝘂𝗹𝗱 𝗳𝗮𝘃𝗼𝗿 𝗡𝘂𝗚𝗲𝘁 𝘃𝗲𝗿𝘀𝗶𝗼𝗻𝗶𝗻𝗴 𝗼𝘃𝗲𝗿 𝗚𝗶𝘁 𝘀𝘂𝗯𝗺𝗼𝗱𝘂𝗹𝗲𝘀 𝗳𝗼𝗿 𝗯𝗶𝗻𝗮𝗿𝘆 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆. 𝗖𝗣𝗠+𝗡𝘂𝗚𝗲𝘁 𝗴𝗶𝘃𝗲𝘀 𝘆𝗼𝘂 𝗰𝗹𝗲𝗮𝗻𝗲𝗿 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗺𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁, 𝘄𝗵𝗶𝗹𝗲 𝗚𝗶𝘁 𝘀𝘂𝗯𝗺𝗼𝗱𝘂𝗹𝗲𝘀 𝗮𝗿𝗲 𝗺𝗼𝗿𝗲 𝗮𝗽𝗽𝗿𝗼𝗽𝗿𝗶𝗮𝘁𝗲 𝗶𝗳 𝘆𝗼𝘂 𝗴𝗲𝗻𝘂𝗶𝗻𝗲𝗹𝘆 𝗻𝗲𝗲𝗱 𝘀𝗼𝘂𝗿𝗰𝗲-𝗹𝗲𝘃𝗲𝗹 𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴.

𝟮. 𝗨𝗺𝗯𝗿𝗲𝗹𝗹𝗮 𝗣𝗮𝗰𝗸𝗮𝗴𝗲 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 (How do we define and distribute a compatible set of messaging dependencies as one versioned unit?) An alternative approach to above technique is the use of Umbrella packages also called meta-packages. This technique involves creating a dedicated NuGet package that groups and declare dependencies on other internal or external package with specific versions. By referencing this umbrella package, each project implicitly brings along all the necessary dependencies at predefined versions. This approach centralizes dependency control without needing to manage multiple configuration files or repositories.

Press enter or click to view image in full size

RabbitMQ change → Shared library → Umbrella package → Controlled service rollout

The goal isn’t just to upgrade RabbitMQ. It’s to 𝗿𝗲𝗱𝘂𝗰𝗲 𝘁𝗵𝗲 𝗯𝗹𝗮𝘀𝘁 𝗿𝗮𝗱𝗶𝘂𝘀 𝗼𝗳 𝘁𝗵𝗲 𝗻𝗲𝘅𝘁 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝗰𝗵𝗮𝗻𝗴𝗲.