add(good-reads): include Hepsiexpress teslimat takip projesi blog

good-reads/README.MD

@@ -4,4 +4,5 @@ Okunmasının faydalı olacağına inanılan, farklı disiplinleri harmanlayan,
 
 - [Unpacking Cloudflare Workers CPU Performance Benchmarks](unpacking-cf-workers-cpu-performance-benchmarks.md)
 - [DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together](ddd-hexagonal-onion-clean-cqrs-how-i-put-together.md)
-- [How Brain Works](how-brain-works.md)
+- [How Brain Works](how-brain-works.md)
+- [Hepsiexpress — Teslimat Takip Projesi](hepsiexpress-teslimat-takip-projesi.md)

good-reads/hepsiexpress-teslimat-takip-projesi.md

@@ -0,0 +1,43 @@
+# Hepsiexpress — Teslimat Takip Projesi
+
+**yazar(lar):** Okay Tonka
+
+**yıl:** 2022
+
+**kaynak/link:** [Medium — hepsiburadatech](https://medium.com/@okay.tonka/hepsiexpress-teslimat-takip-projesi-983011182e69)
+
+## özet
+
+Hepsiburada’nın hızlı teslimat girişimi Hepsiexpress’in saha kurye takip uygulamasının sıfırdan yeniden yazılma sürecini anlatan bir deneyim yazısı. Eski uygulama büyüyen kurye sayısı ve artan anlık veri akışıyla birlikte gecikmeler, kasılmalar ve kilitlenmeler yaşamaya başlayınca ekip yeni bir mimariye geçmeye karar veriyor. Yazı; teknoloji seçimi, veri yapısı tercihi, Socket.IO tabanlı anlık veri akışında yaşanan performans sorunları ve harita üzerindeki binlerce marker’ın verimli bir şekilde render edilmesi gibi konularda alınan kararları ve yapılan optimizasyonları sade bir dille aktarıyor.
+
+Ele alınan başlıca problem: **dakikada on binlerce anlık konum/durum güncellemesinin React tabanlı bir harita arayüzünde performans kaybı olmadan işlenmesi.**
+
+Projenin özet mimari ve teknoloji seçimleri:
+
+- **Frontend:** React + Hooks + Redux
+- **Backend / BFF:** Go, Node.js, MongoDB
+- **API Gateway:** Node.js
+- **Realtime:** Socket.IO
+- **Harita:** Google Maps (aktif olarak bakımı yapılan bir npm kütüphanesi)
+
+Ana optimizasyon fikirleri:
+
+- State’i **Array yerine JSON Object (key’li)** olarak tutmak → arama maliyetini ~12.85 ms’den ~0.06 ms’ye düşürmek
+- Socket üzerinden gelen veriyi doğrudan Redux’a basmak yerine **Cache + Interval** ile toplu gönderim (ör. 100 ms’de 200 veri)
+- **Redux Batch** ile N güncellemeyi 1 render’a indirmek → dakikada 10.000 render’dan 50 render’a düşmek
+- Socket **timeout** ayarlarını düzenleyerek kopmaları önlemek
+- Marker ikonlarını **PNG yerine SVG** yapmak
+- Marker’lara **index yerine id bazlı unique key** vermek ve z-index’i map index’inden almak (göz kırpma / flicker önleme)
+
+## neden ilginç buldum
+
+- Akademik bir makaleden çok, gerçek bir üretim ortamında yaşanmış somut bir “performans hikayesi” — sayılarla birlikte (10.000 render → 50 render) anlatılması fikirlerin etkisini net görmemi sağladı.
+- Teknoloji seçiminin sadece “hangisi daha iyi” değil, **zaman baskısı, topluluk desteği ve ekibin yetkinliği** gibi pratik kriterlerle yapıldığının dürüstçe yazılması (Svelte’in denenip vazgeçilmesi gibi) hoşuma gitti.
+
+## notlar / ilgili kaynaklar
+
+- Makalenin yayınlandığı yer: [hepsiburadatech — Medium](https://medium.com/hepsiburadatech)
+- Kullanılan teknolojiler hakkında referans okumalar:
+  - [Redux Batch / `batch()` — React-Redux docs](https://react-redux.js.org/api/batch)
+  - [Socket.IO — Timeout & Heartbeat](https://socket.io/docs/v4/how-it-works/#disconnection-detection)
+  - [React reconciliation — “Keys” neden önemli](https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key)