Geçen ay, İstanbul Maslak’ta bir kahve molasında yine aynı soru önüme düştü: “Bir e-ticaret uygulamasını Railway’e koyar mısın?” Açık konuşayım — demo için evet. Para dönen, sipariş akışı olan, webhook yağmuru yiyen gerçek bir mağaza içinse iş biraz karışıyor. Hatta baya karışıyor.
Railway’in cazibesi belli tabii. Repo’yu bağlıyorsun, birkaç tıkla canlı URL alıyorsun, veritabanı ekliyorsun… insanın içi rahatlıyor. Ama işin aslı şu ki e-ticaret başka bir oyun. Burada sadece “çalıştı” demek yetmiyor; ödeme anında sistem ayakta kalacak mı, kuyruktaki işler zamanında bitecek mi, stok senkronu sapıtacak mı — bunlara bakıyorsun. Ve bunlara baktığında tablo değişiyor.
Çok konuştum, örnekle göstereyim.
Ben 2024 sonbaharında küçük bir SaaS yan projesini Railway üzerinde denemiştim. Kurulum kısmı gerçekten fena değildi, hatta oldukça akıcıydı. Fakat iki hafta sonra arka plandaki cron işi gecikmeye başlayınca hevesim biraz söndü. O proje para kazanmadığı için sorun olmadı. Ama aynı şey sepet ve ödeme tarafında yaşansaydı… dürüst olayım, pek hoş olmazdı.
Neden İlk Bakışta Çok Mantıklı Görünüyor?
Railway’i kısa sürede sevdiren şeyler var. Arayüz temiz. Başlangıç bariyeri düşük. “Şimdi deploy et” hissi dayanıklı — özellikle küçük ekiplerde bu çok çekici geliyor. Kimse ilk gün DevOps savaşı vermek istemiyor, haklılar da bir açıdan. Bir de fiyatlandırma tarafında giriş eşiği görece makul görününce platform daha da sempatik duruyor.
Gel gelelim e-ticaret dünyasında sempatik görünmek yeterli değil. Hiç yetmiyor aslında. Mağaza sahibi ya da ürün yöneticisi olarak senin derdin estetik panel değil; sipariş kaybı olmaması, ödeme sağlayıcısından gelen webhook’ların kaçmaması. Yoğun saatte siteyi açan müşterinin boş ekran görmemesi. Vitrin güzel olabilir ama depo kapısı kilitleniyorsa o iş yürümez. Basit.
Doğrusu, Editör masasında bu konuyu incelerken kendi kendime şunu not ettim: platformlar çoğu zaman seni ilk gün ikna eder, üçüncü ayda sınar. Ben bunu 2023’te Ankara’daki bir müşteri projesinde de gördüm; ön yüzde her şey tatlıydı. Mail kuyruğu gecikince operasyon ekibi bana sabah sekizde mesaj atmaya başladı. Ne diyeyim… kahve tüketimi artmıştı o dönem, ciddi söylüyorum.
E-Ticarette Asıl Sınav Nerede Başlıyor?
İçerik sitesi ile e-ticaret sistemi arasında ciddi fark var. Ciddi. Bir içerik sitesi bazen birkaç saniyelik gecikmeyi kaldırır — kullanıcı okur geçer, kimse fark etmez. Ama mağazada geciken sayfa doğrudan dönüşümü vurur; sepete ekleme aksarsa satış düşer, checkout yavaşlarsa müşteri kaçar, ödeme sonrası bildirim gitmezse destek talebi patlar. Ve bu domino dizi hızlı işliyor.
İşin kritik tarafı yalnızca HTTP istekleri de değil tabii. Sipariş oluşturma işlemi genelde veritabanına yazıyor, ardından stok kontrolü yapıyor, e-posta tetikliyor, kargo servisine mesaj gönderiyor ve bazen muhasebe sistemine event basıyor — bunların hepsi zincir gibi birbirine bağlı. Zincirin tek halkası gevşerse bütün süreç sarsılıyor. Hatta çöküyor.
Şimdi gelelim işin can alıcı noktasına.
Küçük bir startup için bu durum bazen “idare eder” seviyesinde kalabilir, trafik azsa sorunlar hemen görünmeyebilir. Ama orta ölçekli markada ya da kampanya dönemlerinde tablo değişiyor (yanlış duymadınız). Black Friday benzeri yoğunluklarda platformun dayanıklılığı artık teori değil pratik oluyor. Maalesef.
E-ticarette kötü deploy’un bedeli blog hatasından farklıdır; burada sadece teknik borç değil, doğrudan gelir kaybı konuşulur.
Sipariş Akışı Neden Hassas?
Şöyle düşün: sepet güncellenir, indirim hesaplanır, stok azalır ve ödeme doğrulanır… Hepsi birbirine değmeden çalışmalı. Railway gibi hızlı başlayan platformlar burada bazı ekipleri rahatlatıyor ama üretim disiplinini otomatik olarak sağlamıyor — bunu kimse sağlamıyor zaten, onu ekip yapıyor.
Size bir şey söyleyeyim, Bir de şu var: deployment sırasında servislerin yeniden başlaması veya kısa süreli bağlantı kopmaları bazı sistemlerde tolere edilirken e-ticarette sorun yaratabiliyor. Bilhassa cache ile veritabanı arasındaki tutarsızlıklar çok can sıkıcı olabiliyor — hani müşteriye “stokta var” deyip sonra siparişi iptal etmek gibi tatsız sürprizler. Bunu yaşayan mağazalar biliyor nasıl bir şey olduğunu.
Arka Plan İşleri Sessiz Kalmaz
E-postalar, fatura üretimi, stok eşitleme ve iade akışları genelde sahne arkasında yürür. Kimse görmez. Ama hata olduğunda herkes hisseder — hem müşteri hem operasyon ekibi hem de gece yarısı telefonu açan o talihsiz geliştirici.
| Kritik Alan | Küçük Startup | Büyüyen / Enterprise |
|---|---|---|
| Deploy riski | Bazen tolere edilebilir | Neredeyse kabul edilemez |
| Cron / job güvenilirliği | Düşük hacimde idare eder | Sıkı izleme gerekir |
| Veri tutarlılığı | Basit modellerde yönetilebilir | Ağır test ister |
| Maliyet kontrolü | Tahmin zor olabilir | Bütçe alarmına bağlanmalı |
| Kurtarma senaryosu | Kabaca planlanabilir | Net runbook şarttır |
Railway’in Güçlü Yanları Var mı? Var Tabii.
Lafı gevelemeden söyleyeyim: Railway çöpe atılacak bir platform kesinlikle değil. Hızlı prototipleme için bayağı iyi çalışıyor. Geliştirici deneyimi temiz olduğu için yeni fikirleri ayağa kaldırmak kolaylaşıyor. Bu erken aşama ekiplerde gerçekten büyük avantaj — bunu küçümsemiyorum.
Ama güzel özellik ile üretim güvenilirliği aynı şey değil (bizzat test ettim). Ben bunu geçen yıl İzmir’de çalışan bir arkadaşımın SaaS girişiminde yakından gördüm; panelden memnun kaldılar, her şey şık görünüyordu, ama yük testine girince bazı servisler beklenenden önce tökezledi. Kullanıcı sayısı artmadan fark edilmesi iyi oldu — yoksa can sıkıcı olurdu, epey can sıkıcı. Copilot Alanları Neden Şaşırıyor: Grafikle Düzelen Hafıza yazımızda bu konuya da değinmiştik.
- Kurulumu hızlıdır. (bence en önemlisi)
- Küçük projelerde moral verir. (bu kritik)
- Geliştirici dostu hissettirir.
- Ama ağır üretim yükünde dikkat ister. — ciddi fark yaratıyor
- E-ticarette ise dikkat yetmeyebilir; ekstra disiplin gerekir.
Neyse uzatmayalım: Railway’in en güçlü yani hızdır, en zayıf yani ise hızın verdiği fazla güven duygusu olabilir. İnsan ilk deploy’u görünce “tamamdır” sanıyor. Sonra işler büyüyünce gerçek tablo çıkıyor ortaya. Bu klasik hikaye aslında — bulutta çok sık yaşanıyor, sadece Railway’e özgü bir şey değil bu. Portfolyonuz Mükemmel Görünse de Neden Eski Kalır? yazımızda bu konuya da değinmiştik. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Peki Hangi Senaryoda Mantıklı?
Şöyle söyleyeyim, Eğer elinizde MVP varsa ya da satışa hazır olmayan bir mağaza taslağı üzerinde çalışıyorsanız Railway kullanılabilir demiyorum — direkt faydalıdır diyebilirim. Bilhassa katalog ekranları hazırlarken, admin panel kurarken veya sınırlı trafik alan pilot projelerde işinizi görür. Gayet de görür.
Fakat gerçek para akışı başladığında ölçüt değişiyor (evet, doğru duydunuz). Ödeme altyapısı devreye girince SLA beklentisi yükseliyor, — itiraz edebilirsiniz tabi — webhook tekrar denemeleri önem kazanıyor, log takibi şart oluyor. Bu noktada daha oturmuş bulut mimarileri veya kontrollü container orkestrasyonu çoğu ekip için daha güvenli hissettiriyor —. Genelde öyle de oluyor.
Hmm, bunu nasıl anlatsamdı… Strategy’nin Bitcoin Hamlesi: Dividendi Kurtaran İnce Hesap yazımızda bu konuya da değinmiştik.
Büyük şirketlerde mesele sadece uptime değil zaten. Uyumluluk kontrolleri, erişim politikaları, yedekleme stratejisi ve gözlemlenebilirlik katmanı ayrı ayrı değerlendiriliyor (buna dikkat edin). Kurumsal tarafta Railway’in rahatlığı biraz hafif kalabiliyor; açık konuşayım, her takımın ihtiyacı aynı değil.
Küçük Startup İçin Ne Anlama Geliyor?
Küçük ekipte bütçe baskısı yüksek olur. Orada Railway çekici çünkü karmaşayı azaltıyor. Bir geliştiriciyle iki servis ayağa kalkar, pazara çıkış hızlanır. Ancak gelir gelmeye başladığı anda tekrar düşünmek gerekiyor; aksi halde bugün kurtaran tercih yarın teknik borca dönüşür. Bu dönüşüm hem acı hem de pahalı oluyor çoğunlukla (buna dikkat edin) Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Büyük Ölçek İçin Ne Anlama Geliyor?
Bilmem anlatabiliyor muyum, Büyük ölçekte güvenilirlik artık opsiyon değil. A/B testleri, kampanya patlamaları, bölgesel kesintiler… hepsi hesaba katılıyor. Ben kurumsal projelerde hep şunu gördüm: ilk etapta kolaylık kazandıran platformlar ileride taşınma maliyetini artırabiliyor (ciddiyim). İşte tam burada “iyi fikir” ile “doğru uzun vadeli seçim” ayrılıyor.
Bence Kararı Belirleyen Üç Kriter Var
Birincisi veri katmanı dayanıklılığı. E-commerce verisi nazlıdır — ürün fiyatları değişir, stok oynar, kampanyalar başlar biter, hepsi eş zamanlı. İkincisi background job davranışı; sipariş sonrası işlemler dakiklik ister, “biraz geç gönderildi” kabul edilebilir değil. Üçüncüsü de deploy güveni; gece yarısı yapılan güncellemenin sabah kasa ekranını bozmasını kimse istemez. Hiç kimse.
# E-ticaret için hızlı kontrol listesi
- Checkout yolu %99+ stabil mi?
- Webhook retry mekanizması var mı?
- DB backup otomatik mi?
- Background worker ayrılmış mı?
- Deploy sonrası smoke test koşuyor mu?
- Log/metric/alert üçlüsü hazır mı?
- Trafik artınca yatay ölçek planlı mı?
Nihai Yargım Ne?
Açıkçası ben olsam ciddi e-ticaret yükünü bugün hâlâ Railway’e emanet etmem (yanlış duymadınız) (ilk duyduğumda inanamadım). Deneme ortamında, erken aşama vitrinde ya da düşük riskli pilotta tamam. Ama kart bilgisi, sipariş durumu, stok eşitleme ve post-purchase akışları devreye girdiyse temkinli davranırım. Bu benim kişisel çizgim.
Ne yalan söyleyeyim, Tabii bu konuda %100 kara-kutu hüküm vermek doğru olmaz. Her takımın mühendislik kapasitesi farklı, her ürünün trafik profili farklı. Hmm, nasıl desem… Ama genel resme baktığımda Railway’in gücü hızda, e-ticaretin ihtiyacı ise istikrarda yatıyor. Bu ikili her zaman aynı yerde buluşmuyor. İşte problem orada başlıyor.
Az önce sadece eksilerini anlattım gibi oldu ama hakkını vereyim: öğrenme eğrisi düşük olduğu için yeni ekiplerin elini çabuklaştırıyor, bu değerli bir şey. Yine de benim notum net — demo mükemmel, production ise ayrı sınav. Ve o sınavda sorular biraz sert geliyor (kendi tecrübem)
Sıkça Sorulan Sorular
Railway e-ticaret sitesi barındırmak için uygun mu?
Küçük ölçekli ya da test amaçlı mağazalar için uygun olabilir. Ancak ödeme akışı, sipariş yönetimi ve yoğun trafik söz konusuysa dikkat etmek gerekir. Ciddi production kullanımında risk analizi yapmak şarttır.
Neden e-ticaret uygulamaları normal web sitelerinden daha zor?
Çünkü e-ticarette sadece sayfa açılması yetmez; sepet güncellemesi, ödeme doğrulaması,stok eşitlemesi ve arka plan işleri de sorunsuz çalışmalıdır. Küçük bir hata bile doğrudan satış kaybına dönüşebilir.
Railway hangi durumda mantıklı seçim olur?
Açıkçası, MVP geliştirme,düşük trafikli pilot projeler iç araçlar için mantıklı olabilir. Ayrıca hızlı prototipleme isteyen küçük ekiplerde zaman kazandırır. Ama büyüme sinyali gelince yeniden değerlendirmek iyi fikirdir.
E-ticarette hangi altyapı özelliklerine bakmalıyım?
Dikey/yatay ölçekleme seçenekleri,yedekleme,gözlemlenebilirlik,retry mekanizmaları ve deployment güveni öne çıkar. Ayrıca database performansı ile queue yönetimi büyük ihtimalle test edilmelidir.
Kaynaklar ve İleri Okuma
Railway Resmî Dokümantasyon Sayfası
Production Readiness Checklist Referansı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
