1. Латентность сети - определённый вид декомпозиции вынуждает сервисы часто обмениваться данными. Есть много способов минимизировать эту проблему, начиная от перепроектирования, и заканчивая реализацией API для извлечения нескольких объектов за один вызов.
2. Синхронное межпроцессорное взаимодействие: если один сервис оказался заблокированным, мы не сможем синхронно к нему обратиться, что ухудшит доступность.
3. Обеспечивание согласованности: если один вызов подразумевает обновление информации в нескольких сервисах - нужно что-то вроде логической транзакции, чтобы данные остались согласованными.
4. Получение согласованного представления данных: разные БД могут выдавать не согласованные данные в контексте одного процесса.
5. Божественные классы: раздутые классы, используемые в разных частях приложения. Проблема тут очевидна - слишком сильная связанность. Одно из решений - упаковка такого класса в библиотеку и создание центральной базы. Проблема тут в том, что такой подход нарушает принципы микросервисной архитектуры и, опять же, приводит к связыванию. Ещё одно решение - сделать для разных сервисов свою модель класса, привязав его только к тем возможностям, которые требует данный сервис. Например, в сервисе Delivery класс Order будет работать с адресом получения, временем получения, адресом и временем доставки.
Тот же класс Delivery в сервисе ресторанов будет работать с только с тем, что связывает заказ и рестораны.