कुनै साझा डेटाबेस नभएको अवस्थामा, तपाई क्रस-सेवा JOINs वा एकल ACID लेनदेन प्रयोग गर्न सक्नुहुन्न। तपाई API composition, replication/CQRS read models, र events प्रयोग गरेर डेटा संयोजन गर्नुहुन्छ र यसलाई सुसंगत राख्नुहुन्छ।
— एक समन्वयकर्ताले प्रत्येक सेवालाई कल गर्छ र परिणाम जोडिन्छ:
// build an order view from three services
const order = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId); // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
भारी क्वेरीहरूको लागि, एक read model (CQRS) राख्नुहोस्: एक सेवाले ईभेन्टहरूमा सदस्यता लिन्छ र यसले सीधै क्वेरी गर्न सक्ने एक denormalized स्थानीय प्रतिलिपि बनाउँछ।
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Saga ढाँचा प्रयोग गर्नुहोस् — प्रतिपूरक कार्यहरूसहित स्थानीय लेनदेनको क्रम — वितरित लेनदेनको सट्टामा।
| दृष्टिकोण | लाभ | हानि |
|---|---|---|
| API composition | सधैं ताजा | Latency, fan-out, भंगुर |
| Replicated read model | द्रुत पढ्न | अन्तत: सुसंगत |
| Saga | 2PC आवश्यक छैन | जटिल, क्षतिपूरक आवश्यक |
जोडिन सजिलो बनाउन "मात्र" एक तालिका साझा गर्नुहोस् नगर्नुहोस् — यो सेवाहरूलाई पुनः युग्मित गर्छ। जहाँ व्यवसायले अनुमति दिन्छ त्यहाँ अन्तत: सुसंगतता स्वीकार गर्नुहोस्।
डेटा प्रबन्धन वह जागा हो जहाँ microservices साँच्चै कठिन हुन्छ, किनकि सजिलो उपकरणहरू (joins, transactions) डिजाइन द्वारा हराएका छन्।
Composition, read models, र sagas बुझ्न वह कुरा हो जसले तपाईलाई सेवाहरूलाई स्वतन्त्र राख्न र सहीपनता गुमाएर नदिन दिन्छ।