← Bütün Patternlər
🕸️

Shared Database

Bütün servislər eyni bazanı paylaşır — anti-pattern sayılsə da, real həyatda tez-tez rast gəlinir. Xüsusilə monolit→mikroservis keçid dövründə.

⚠️
Anti-Pattern!

Bu pattern adətən tövsiyə olunmur. Lakin monolit-dən mikroservisə keçid dövründə qısamüddətli keçid strategiyası kimi istifadə edilir.

🔗
Problem

Tight Coupling: bir servisin sxem dəyişikliyi digər servislərə təsir edir. Müstəqil deployment demək olar ki mümkün deyil.

🔀
Nə vaxt istifadə olunur?

Legacy sistem keçidi, kiçik komandalar, data bütövlüyü (referential integrity) vacib olduqda, MVP dövründə.

İNTERAKTİV

Vizual İzah

Mərhələ {{ currentStep + 1 }}: {{ steps[currentStep].title }}

👤
User Service
🛒
Order Service
💳
Payment Service
⬇️ ⬇️ ⬇️
🗄️

ORTAQ BAZA

PostgreSQL — users, orders, payments tabloları
⚠️ Order Service "users" cədvəlinə birbaşa baxır!
JAVA

Kod Nümunəsi — Problemin Görünüşü

OrderService.java (Shared DB anti-pattern)
@Service
public class OrderService {

    @Autowired
    private JdbcTemplate jdbc;

    public OrderDto createOrder(Long userId, BigDecimal amount) {
        // ❌ PROBLEM: Order servisi birbaşa "users" tablosuna SELECT edir
        // User service-in sxem dəyişikliyi bizi SIRAR!
        String sql = "SELECT name, email FROM users WHERE id = ?";
        Map<String, Object> user = jdbc.queryForMap(sql, userId);

        // Sifariş yarat — eyni bazaya
        jdbc.update("INSERT INTO orders (user_id, total) VALUES (?, ?)",
            userId, amount);

        return new OrderDto(user.get("name"), amount);
    }
}
✅ Qısamüddətli Üstünlükləri
  • JOIN əməliyyatlarını asanlıqla etmək olur
  • ACID tranzaksiyalar əldə edilir
  • Sürətli MVP / tez başlama üçün rahatdır
⚠️ Ciddi Problemlər
  • Tight Coupling — sxem dəyişikliyi hamını sındırar
  • Müstəqil deploy mümkün deyil
  • Scaling çox çətindir (DB bottleneck)
  • Müstəqil texnologiya seçmək mümkün deyil