Nerede ne tutulur
Aynı kavram bazen iki yerde görünür. Bu hata değil: biri kart, biri hareket veya anlık kopyadır.
Hızlı tablo
| Kavram | Asıl kayıt | Hareket / belge | Kopya / indeks |
|---|---|---|---|
| Kullanıcı | MySQL User | Mongo userLogs | Siparişte UserCopy |
| Alıcı | MySQL Buyer | CRM ve grup değerlendirme | Siparişte BuyerCopy |
| Ürün | MySQL Product (+ seçenekler) | — | Sipariş kalemi, MeiliSearch |
| Depo stok miktarı | MySQL WarehouseProduct.stock | Mongo giriş/çıkış | Sipariş kalemindeki referanslar |
| Cari bakiye | MySQL FinancialAccount.balance | Mongo accountTransactions | — |
| Kasa / banka | MySQL MoneyAccount | MySQL MoneyMovement | — |
| Gider | MySQL Expense | MySQL PayablePayment ile ödeme bağı | — |
| Sepet | MySQL ProductBasket | Sipariş oluşunca silinir | — |
| Sipariş | — | Mongo buyerOrders | BigQuery orders |
| Ödeme işlemi | — | Mongo payments | Siparişte purchase.payment ref |
| Fatura | MySQL sıra numarası | Mongo invoices | Siparişte invoice özeti |
| Arama | MySQL ürün/fiyat kartları | — | v1: MeiliSearch product; v2: doğrudan sorgu |
| Push jetonu | MySQL UserDevice | — | UserCopy.devices |
Neden sipariş MySQL’de değil?
Bir sipariş kalem, teslimat, ödeme kırılımı, geçmiş, fatura özeti ve transfer bağlantısını tek belge olarak taşır. İlişkisel tablolara bölmek N+1 ve şema evrimi maliyeti doğurur. Bu yüzden yaşam döngüsü Mongo’dadır.
Neden bakiye MySQL’de?
Bakiye sık okunur, tek sayıdır, kullanıcı+depo ile tektir. Defter ise append-only belgedir. Okuma bakiyeden, tartışma defterden yapılır. Defterdeki balance alanı o hareketten sonraki bakiyenin anlık görüntüsüdür.
Geçiş boyunca v1 financial yolları da v2 LedgerService yolları da Mongo accountTransactions ve MySQL FinancialAccount.balance üzerinde çalışır. LedgerService, platformun değil v2 içindeki cari yazmalarının tek kapısıdır.
Gömülü kopya ne demek?
Sipariş yazılırken alıcı adı, depo adı, ürün birimi belgenin içine kopyalanır. Ertesi gün ürün adı değişse eski sipariş eski adla kalır. Güncel kart her zaman Prisma’dadır.
MeiliSearch
v1'de indeks ürün araması içindir; sipariş araması değildir. Saatlik tam yenileme üretimde Prisma’dan okuyup indeksi baştan kurar. Anlık güncelleme product.upsert / product.deleted olaylarıyladır.
v2 yeni mobil kataloğu MeiliSearch kullanmaz. Ürün araması ProductSearchDecider kurallarıyla doğrudan MySQL verisi üzerinde yapılır; sepet ve sipariş de aynı fiyat/satılabilirlik kararlarını kullanır.