Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
A friend is involved in rewriting a distributed software application and while discussing the architecture, we noticed that in many cases the messages had duplication between headers and payload. ...
#1: Initial revision
When is it OK for duplication of information between message header and payload in a distributed software application?
A friend is involved in rewriting a distributed software application and while discussing the architecture, we noticed that in many cases the messages had duplication between headers and payload. The headers mostly include metadata such as a correlation id, a phone number identifier, client identifier, which is mostly used for logging purposes. Depending on business logic, the payload may also include one or several properties also found in the headers. Due to some limitations of the queuing technology both headers and payload are always included in the HTTP message (i.e. not using queue message metadata). The arguments discussed and researched so far include: - **DRY violation** - payload should not include information already in the headers, as it might lead to errors (what happens if the same property has different values in the same message?) - **separation of concerns/client convenience** - consumers' business logic should not bother reading headers and rely on the fact that all business-related information is provided in the payload - **possible serialization issues** - if a use case requires payload serialization, the client needs to do extra work to also include relevant header information I am wondering if there are any best practices defined for such cases, as it is not clear how to correctly decide if a DRY violation makes sense in this case or not.