Chatty Services: Microservices yang Terlalu Cerewet dan Bikin Sistem Lambat Diam-Diam

Microservices harusnya bikin sistem lebih scalable. Tapi ironisnya, banyak sistem microservices justru jadi lebih lambat dari monolith lama yang mereka gantikan.

Bukan karena salah pilih bahasa. Bukan karena kurang powerful. Tapi karena servicenya… terlalu cerewet.

Kalau satu operasi bisnis butuh 8–12 panggilan API antar service secara sinkron, itu bukan arsitektur modern. Itu Chatty Services — anti-pattern yang pelan-pelan menggerogoti performa dan stabilitas sistem terdistribusi.

Dan ini sering tidak terasa di awal.

Masalahnya Bukan Microservices. Masalahnya Cara Ngobrolnya.

Chatty Services terjadi ketika satu service harus bolak-balik request ke banyak service lain hanya untuk menyelesaikan satu proses sederhana.

Contohnya begini.

class OrderService {
  async processOrder(orderId) {
    const order = await orderAPI.getOrder(orderId);
    const customer = await customerAPI.getCustomer(order.customerId);
    const paymentValid = await paymentAPI.validatePayment(order.paymentId);
    const availability = await inventoryAPI.checkAvailability(order.productId);
    const shipping = await shippingAPI.calculateShipping(order.address);
    const paymentResult = await paymentAPI.processPayment(order.total);
    await inventoryAPI.updateStock(order.productId, -order.quantity);
    await notificationAPI.sendConfirmation(order.customerId, orderId);
    return { success: true, orderId };
  }
}

Kelihatannya rapi. Modular. Setiap service punya tanggung jawab jelas.

Tapi lihat lebih dalam: satu processOrder butuh delapan network call. Kalau satu call rata-rata 30–50ms, total latensi bisa ratusan milidetik — itu dalam kondisi normal. Tambahkan retry, network jitter, atau timeout kecil saja, efeknya bisa meledak.

Chatty services - sequence flow with API requests and responses

Di monolith, ini mungkin cuma function call. Di microservices, ini network boundary. Setiap boundary itu mahal.

Dan yang lebih bahaya: coupling-nya meningkat. OrderService sekarang tahu terlalu banyak tentang cara kerja service lain.

Over-Decomposition: Terlalu Rajin Memecah

Salah satu penyebab utama Chatty Services adalah over-decomposition.

Kita terlalu semangat memecah sistem jadi service kecil-kecil, sampai lupa satu hal penting: distributed system itu kompleks secara alami.

Banyak tim membaca buku seperti Building Microservices karya Sam Newman atau Designing Data-Intensive Applications oleh Martin Kleppmann — lalu fokus ke “pecah jadi kecil”. Tapi lupa bahwa setiap pemisahan menambah cost komunikasi.

Microservices bukan soal jumlah service. Itu soal boundary bisnis yang jelas.

Kalau satu business flow harus lompat-lompat antar lima domain hanya untuk validasi data, mungkin boundary-nya salah.

Latensi Itu Aditif. Error Itu Menular.

Dalam sistem terdistribusi, latensi bersifat aditif. Error bersifat propagatif.

Kalau satu service punya 1% failure rate, dan kamu panggil 10 service secara sinkron, probabilitas kegagalan total meningkat drastis.

Itulah kenapa Chatty Services sering jadi biang:

Timeout berantai
Retry storm
Network congestion
Testing yang ribet karena harus mock setengah sistem

Masalahnya jarang muncul di local development. Biasanya baru terasa di production saat traffic naik.

Dan di titik itu, debugging-nya menyakitkan.

Alternatifnya? Kurangi Obrolan, Perjelas Boundary

Solusinya bukan “balik ke monolith”. Itu respons emosional.

Solusinya adalah desain komunikasi yang lebih strategis.

Perhatikan versi ini:

class OrderService {
  constructor(orderProcessor) {
    this.orderProcessor = orderProcessor;
  }
  async processOrder(orderData) {
    const result = await this.orderProcessor.processCompleteOrder(orderData);
    await eventBus.publish('OrderProcessed', {
      orderId: result.orderId,
      customerId: orderData.customerId
    });
    return result;
  }
}

Dan di dalam OrderProcessor:

class OrderProcessor {
  async processCompleteOrder(orderData) {
    const [customer, payment, inventory, shipping] = await Promise.all([
      this.customerRepo.get(orderData.customerId),
      this.paymentService.validate(orderData.paymentId),
      this.inventoryService.checkAndReserve(orderData.productId, orderData.quantity),
      this.shippingService.calculate(orderData.shippingAddress)
    ]);
    const paymentResult = await this.paymentService.charge(orderData.paymentId, shipping.total);
    if (paymentResult.success) {
      await this.inventoryService.confirmReservation(orderData.productId, orderData.quantity);
      const order = await this.orderRepo.create(orderData);
      return { success: true, orderId: order.id };
    }
    return { success: false, reason: 'Payment failed' };
  }
}

Di sini, komunikasi dikonsolidasikan. Operasi dilakukan lebih terkoordinasi. Event digunakan untuk proses lanjutan yang tidak harus sinkron.

Chatty synchronous calls vs consolidated call + event-driven flow

Bukan berarti semua harus async. Tapi tidak semua hal harus request-response berantai.

API Itu Harus Dirancang untuk Inter-Service, Bukan UI

Banyak API awalnya dibuat untuk frontend. Endpoint kecil, granular, fleksibel. Lalu endpoint yang sama dipakai antar service.

Hasilnya? Service saling fetch data potongan demi potongan.

Padahal komunikasi antar service seharusnya lebih coarse-grained. Satu request membawa konteks lengkap, bukan serpihan data.

Kadang solusi paling sederhana adalah:

Bulk operation
DTO yang membawa seluruh konteks
API composition layer
Atau bahkan pendekatan event-driven

Tools seperti GraphQL bisa membantu agregasi data. Service mesh seperti Istio atau Linkerd membantu observability dan reliability. Event streaming seperti Apache Kafka atau RabbitMQ membuka opsi async processing.

Tapi tool bukan solusi utama. Desain adalah kuncinya.

Pertanyaan yang Jarang Ditanyakan

Sebelum menambah satu service baru, ada satu pertanyaan yang seharusnya ditanyakan:

Apakah ini mengurangi kompleksitas… atau hanya memindahkannya ke network?

Chatty Services bukan kegagalan teknologi. Ia lahir dari ilusi modularitas. Terlihat rapi di diagram arsitektur. Terlihat clean di slide presentasi. Tapi di production, ia berbicara terlalu banyak — sampai sistemnya sendiri kehabisan napas.

Microservices seharusnya membuat sistem lebih independen. Kalau setiap fitur baru menambah lima panggilan API tambahan, mungkin yang perlu diperbaiki bukan performanya — tapi cara servicenya berbicara satu sama lain.

Tags:

Pengetahuan