Microservices vs Monolith — Kiçik Komanda üçün Doğru Seçim

Microservices vs Monolith — Kiçik Komanda üçün Doğru Seçim

Salam, developer dostum. Bu gün Bakıda hər müsahibədə soruşulan, hər texniki söhbətdə qaynayan mövzuya toxunuruq: Microservices vs Monolith. Amma bu dəfə nəzəri deyil — sənin reallığın üçün danışacağıq.

Əgər 3-7 nəfərlik komandada işləyirsənsə, startup qurursan, ya da Bakıdakı outsource şirkətdə layihəyə yeni başlayırsan — bu məqalə sənin üçündür.

---

Əvvəlcə, sadə tərif

Monolith — bütün kodun bir yerdə olduğu, bir deploy ilə çıxan tətbiq. Bir repo, bir database, bir process.

Microservices — tətbiqin kiçik, müstəqil servislərə bölündüyü arxitektura. Hər servis öz database-i, öz deploy-u, öz həyatı.

Sadə desək: monolith — bir böyük ev, microservices — hər otaq ayrı binadır.

---

Bakı reallığı: Rəqəmlər danışsın

Gəlin yerli kontekstə baxaq. Azərbaycanda orta bir startup və ya outsource layihəsinin reallığı belə görünür:

• Komanda ölçüsü: 3-7 developer
• DevOps mütəxəssisi: çox vaxt yoxdur, ya da backend developer həm də DevOps rolunu oynayır
• İnfrastruktur büdcəsi: ayda 200-600 AZN (AWS/DigitalOcean)
• Maaş reallığı: Middle backend developer — 1500-2500 AZN, Senior DevOps — 3000-4500 AZN
• Layihə deadline-ı: "Dünən lazım idi"

İndi düşün: 5 nəfərlik komandada dedicated DevOps yoxdursa, Kubernetes cluster-i kim idarə edəcək? Hər servisin CI/CD pipeline-ını kim yazacaq? Distributed tracing-i kim quraşdıracaq?

Cavab sadədir: heç kim. Çünki büdcə yoxdur, vaxt yoxdur, adam yoxdur.

---

Microservices-in gizli xərcləri

Hamı Netflix-in, Uber-in arxitekturasını oxuyub ilhamlanır. Amma unudurlar ki:

ThoughtWorks-un 2025-ci il Technology Radar hesabatına görə, kiçik komandaların 68%-i microservices-ə keçdikdən sonra ilk 6 ayda productivity itkisi yaşayıb. Martin Fowler-in məşhur prinsipi hələ də aktualdır: "Monolith first".

---

Bəs nə etməli? Modular Monolith

Cavab ortadadır: Modular Monolith. Bir tətbiq içində modul sərhədlərini düzgün qur, sabah lazım olanda servisə çıxart.

Budur, real bir Node.js (NestJS) layihə strukturu:

src/
├── modules/
│   ├── auth/
│   │   ├── auth.module.ts
│   │   ├── auth.controller.ts
│   │   ├── auth.service.ts
│   │   └── entities/
│   │       └── user.entity.ts
│   ├── orders/
│   │   ├── orders.module.ts
│   │   ├── orders.controller.ts
│   │   ├── orders.service.ts
│   │   └── entities/
│   │       └── order.entity.ts
│   └── payments/
│       ├── payments.module.ts
│       ├── payments.controller.ts
│       ├── payments.service.ts
│       └── entities/
│           └── payment.entity.ts
├── shared/
│   ├── database/
│   ├── guards/
│   └── interceptors/
└── app.module.ts

Və modullar arası əlaqənin necə olmalıdır — bir nümunə:

typescriptKopyala
// orders/orders.service.ts
import { Injectable } from '@nestjs/common';
import { PaymentsService } from '../payments/payments.service';
import { EventEmitter2 } from '@nestjs/event-emitter';

@Injectable()
export class OrdersService {
  constructor(
    private readonly paymentsService: PaymentsService,
    private readonly eventEmitter: EventEmitter2,
  ) {}

  async createOrder(dto: CreateOrderDto) {
    const order = await this.orderRepo.save(dto);

    // Modul arası əlaqə: event-driven yanaşma
    // Sabah microservice olsa, bu event RabbitMQ-ya keçər
    this.eventEmitter.emit('order.created', {
      orderId: order.id,
      amount: order.totalAmount,
    });

    return order;
  }
}

typescriptKopyala
// payments/listeners/order-created.listener.ts
import { OnEvent } from '@nestjs/event-emitter';
import { Injectable } from '@nestjs/common';

@Injectable()
export class OrderCreatedListener {
  @OnEvent('order.created')
  async handleOrderCreated(payload: { orderId: string; amount: number }) {
    // Bu gün in-process event, sabah RabbitMQ consumer
    await this.paymentsService.initializePayment(
      payload.orderId,
      payload.amount,
    );
  }
}

Diqqət et: modullar bir-biri ilə event vasitəsilə danışır. Bu gün EventEmitter2 in-memory işləyir. Sabah komandan böyüyəndə, order.created event-ini RabbitMQ-ya yönləndirirsən — və payments modulu artıq ayrı servisdir. Kodu yenidən yazmağa ehtiyac yoxdur.

---

Nə vaxt microservices-ə keçməli?

Bu checklist-ə bax. Əgər ən azı 4-ü doğrudursa, keçid haqqında düşünə bilərsən:

• ✅ Komandada 15+ developer var
• ✅ Fərqli modullar fərqli scaling tələb edir (məsələn, payments 10x daha çox traffic alır)
• ✅ Dedicated DevOps/Platform engineering komandası var
• ✅ CI/CD pipeline monolith üçün 30+ dəqiqə çəkir
• ✅ Fərqli komandalar fərqli release cycle istəyir
• ✅ İnfra büdcəsi ayda 2000+ AZN-dir

Əgər bunların çoxu sənə tanış deyilsə — monolith sənin dostundur.

---

Müsahibə üçün qızıl cavab

Bakıda texniki müsahibələrdə bu sual çox verilir. İşə yarayan cavab:

"Microservices güclü arxitekturadır, amma hər problem üçün doğru həll deyil. Mən kiçik komandada modular monolith ilə başlamağı, modul sərhədlərini event-driven şəkildə qurmağı, lazım olan anda isə spesifik modulu ayrı servisə çıxarmağı üstün tuturam. Bu yanaşma həm development speed-i qoruyur, həm də gələcəyə hazırlıq yaradır."

Bu cavab sənin həm praktiki təcrübəni, həm də arxitektura düşüncəsini göstərir.

---

Yekun: Pragmatizm qalib gəlir

Texnologiya seçimi ego ilə deyil, kontekstlə olmalıdır. Sənin kontekstin:

• Kiçik komanda → Monolith (modular)
• Məhdud büdcə → Monolith
• Sürətli delivery lazım → Monolith
• Gələcəkdə scale lazım ola bilər → Modular Monolith + event-driven

Netflix microservices ilə dünyanı fəth etdi, amma Netflix-in ilk versiyası da monolith idi. Amazon-un ilk arxitekturası da monolith idi. Sən də oradan başla.

Doğru arxitektura — komandanın bu gün idarə edə biləcəyi arxitekturadır.

Kod yaz, deploy et, istifadəçidən feedback al. Qalanı sonra gələr. 🚀

---

Bu mövzu haqqında sualın varsa, şərhlərdə yaz. Növbəti məqalədə "Modular Monolith-dən microservices-ə real migration" nümunəsi göstərəcəyik.