Both are viable. They have their tradeoffs.
First one is easier, but if Order service is down, so is Fullfilment service. It also becomes a problem with overall stability. If a service depends on 3 other services, and those have stability of 99.5%, then the service itself would have 0.995^3 = 0.985 = 98.5% . This might be unacceptable. And when you have dozens of services with many instances, these numbers quickly add up.
Second is more difficult, but Fullfilment service can work even when Order service is down. It also allows the Fullfilment service to store the data in a way that is easy for it to consume. This might not be true for whatever API the other services provide for it.
Third option is to use ‘delayed’ creation. In this scenario, the Fullfilment service tracks the state of it’s request in persistent storage and starts it in ‘is being fullfilled’ state. Then, it sends asynchronous message to Order service, which Order service will process when it is up and ready. Once it is done, it will send response back to Fullfilment service, which will continue in the processing. This is different form of complication than keeping copy of the data, as you need to keep track of fullfilment state and revert it if something goes wrong (eg. with saga). And it requires client of Fullfilment service to know that it’s request can be in ‘to be finished’ state. But it gives you advantage of high stability and no need to keep duplicate data.