persist a single payload which is targeted for multiple service

[sachinda123456]

Whats the recommended way to persist a single payload which is targeted for multiple services?
I have two molecular services which are named Invoice and InvoiceRow.
Only one request comes in with a combined payload which holds both invoice and invoice row data.
Currently I'm separating data inside the invoice service action and just make a static action call to invoice row to persist row data. Then same for the invoice main data.
I just want to check with the community on my current practice. In a architecture like one database per service, Whats the recommended way to persist a single payload which is targeted for multiple services?
Sample payload.

{
   "customer":1,
   "credit_invoice_id":null,
   "payment_status":1,
   "taxType":null,
   "discountRate": null,
   "invoiceRows": [
            {
           "quantity":213,
           "amount":"3.79",
           "currency": 1,
           "description": ""
       }
     ]
}

[ccampanale]

As far as the technical approach, as I suggested previously, I again suggest reading the Moleculer Documentation for Database Adapters and examples. Regardless of how you are design the services in your system/application this documentation should be able to shed some light on how one might implement persistence to various database systems. Of course, you are not bound by the available database adapters and could cook something of your own up. (Most of my teams' projects use custom adapters as our microservices often have a correlation to application layer services which are not limited to a single domain model which was at least originally the case with some of the provided adapters.)

From a microservice architecture best practice you are correct that it is recommended that each microservice maintain its own database forcing other services to interface with the service rather than the data itself in order to enforce strong boundaries and invariants within your system.

That being said, I'm not sure about your services' separation of concerns; you have not provided much detail around the problem domain you're a solving and why you have chosen to split Invoice and Invoice Rows into separate services. It's hard for me to really argue against or for this design because I don't know why you've chosen to do this. Please feel free to elaborate...

Regardless of the above, it sounds like you are correctly implementing the inter-service calls to do what you have explained you are intending to do; calling the invoice row service in order persist the row data, awaiting the success, then subsequently persisting the invoice data. There are of course other details you may want to take into consideration such as "how to handle a failure persisting/committing the invoice data"; e.g. "should the invoice row state be rolled back?", etc. Because you have separated these services you are setting yourself up for needing to implement what is commonly referred to as "Sagas" in microservice architectures. Essentially these are state machines for handling multi-service transactions within a microservice system. If you are going to be building systems using this framework - or any microservice framework in any language - I highly recommend reviewing the collected knowledge on https://microservices.io.