We're currently considering building an app's backend using an Event Driven Microservices Architecture. From what I've learned, this means you should be replicating data which is used by multiple services using asynchronous messaging, instead of directly querying the data holding service.
Imagine we need to implement a service, which holds lots of foreign keys from other services, e.g: market ID's, user ID's, and few others. The service should not just respond with the plain ID's, but map them to their according names, e.g: idmarket1 -> "Walmart", idname1 -> "John Doe".
Option 1: Providing both the ID's and corresponding names in the post request to create a record, along with the other fields. This could lead to users messing with the API to be able to manipulate the names.
Option 2: Replicating the ID-Name-Pairs to the service via a pub sub message broker, whenever a new record is created in one of the others stores owning the data.
The second option seems like the way to go for me, but I'm not sure if it's really the best practice to be replicating such small chunks of data, each in an extra table.
Are there any other options or best practices, I haven't considered yet?