Logical Endpoint Design: System Boundary vs Business Capability Boundary

Architecture & Design
,
1

Hi, I am currently working on a multi-system integration project where several business systems need to communicate with SAP. The first phase of this project is to build an integration system between a WMS and SAP.

After learning about messaging frameworks, I am considering using NServiceBus. I have been reading through the official documentation, but I still have some questions regarding Logical Endpoint design.

I would like to share my current understanding and would appreciate any advice or experience from the community, people who have designed similar integration platforms.

For the WMS-SAP integration scenario, the main business areas may include:

  • Inbound processing
  • Outbound processing
  • Data Synchronization
  • Inventory management
  • Miscellaneous operations

At the moment, I am considering two possible approaches.

Option 1: Based on systems

  • WMS Endpoint
  • SAP Endpoint

This approach is easier for me to understand because when a new external system is introduced in the future, I can add a new endpoint based on the system boundary.

However, I am concerned about scalability.

For example, if one specific WMS business process becomes slow or requires independent scaling in the future, would I eventually need to split it into a separate logical endpoint?

If so, the original “system-based endpoint design” may become difficult to maintain.

Option 2: Based on business capabilities

  • WMS-Inbound Endpoint
  • WMS-Outbound Endpoint
  • Data-Sync Endpoint
  • Inventory Management Endpoint
  • Misc-Operation Endpoint

This seems to provide better isolation between different business areas.

However, I am concerned about creating too many endpoints. Since Logical Endpoints also have licensing and operational considerations, excessive fragmentation may introduce unnecessary complexity.

Based on mu current understanding, a Logical Endpoint should represent a boundary that requires:

  • Independent message queue
  • Independent deployment
  • Independent scaling
  • Independent failure isolation

With this understanding, I am wondering whether both approaches above are too extreme.

My current idea is to start like:

  • WMS-Operation Endpoint
  • WMS-Sync Endpoint

The reason is that the current WMS message throughput is small (less than 10,000 messages/day), so this may provide a reasonable balance between isolation and simplicity.

My questions are:

  1. What principles do you usually follow when defining Logical Endpoint boundaries?
  2. Should endpoints normally align with business capabilities, technical responsibilities, or external systems?

I would really appreciate any advice, best practices, or examples from your experience.

Thank you!

2

Hi Conrad,

I wanted to summarize some of the things we discussed in our call here in case they are helpful for anyone else that finds this post.

There are several considerations when deciding how to bundle message handlers into logical endpoints:

  • Do the message handlers rely on common infrastructure that needs to be updated at the same time? If so, consider bundling them.
  • Do the message handlers need to be scaled up/down together or separately? The unit of scale is the endpoint, so if you have one message handler that needs to be scaled up, does it make sense that the other message handlers would need to be scaled up as well? If so, consider bundling them.
  • Each endpoint has a single input queue. That means that messages of multiple types will exist in the same queue. Is it OK that messages of one type can be blocked by messages of another type? If you want some messages to “skip the queue” consider putting them in a separate, dedicated endpoint.
  • The endpoint is also the unit of configuration for things like transaction handling and error handling. If you need different error handling configuration for different message types, then consider splitting them into separate endpoints based on those requirements.

You mentioned SAP, and we would recommend having a single endpoint that integrates with SAP. That gives you control over concurrent SAP access, and isolates changes in that integration to a single place within your system. We discussed that some messages may require more priority, so it may make sense to create high-priority and low-priority integration endpoints and control how much access each gets with scaling and concurrency settings. For instance, if you create these two endpoints with a concurrency of 2, you can scale the high-prioity instance to 3 instances (total concurrency of 6) and the low-priority instance to 2 instances (total concurrency of 4) for an overally concurrency of 10. Then you can scale these instances up and down to adjust the mix of messages based on workload.

We discussed splitting an endpoint after it has been deployed and this can be done, but you need to consider any messages in the input queue of the original endpoint. Here is the process we discussed.

  1. Deploy the new endpoints, leaving the old one in place
  2. Adjust the routing of other endpoints to send messages to the new one
  3. Wait for the input queue of the old endpoint to be empty (NOTE: If you have delayed messages then you should wait until these have been delivered as well)
  4. Decomission the old endpoint

I hope that helps, and feel free to reach out if there’s anything else we can assist you with.