Ordovia — Ürün ve Sistem Mimarisi | Ahmet Canal

/01

Bağlam

Ordovia'nın hedefi yeni bir todo uygulaması üretmek değildi. Birbirinden farklı kişisel üretkenlik domainlerini aynı kullanıcı, aynı gün ve aynı senkronizasyon modeli altında tutarlı çalışan tek ürüne dönüştürmekti.

/02

Problem

Görevler, notlar, ritüeller, planlama, takvim ve bilgi grafiği birbirinden farklı veri modellerine sahip. Üstelik ürün web, mobil ve masaüstünde aynı hesabı ve aynı kaynak veriyi güvenilir şekilde taşımalı.

/03

Rolüm

Ürün mimarisi
Sistem mimarisi
Frontend / backend entegrasyonu
Senkronizasyon ve yayın operasyonu

/04

Çözüm

Tek web ürün katmanını ortak domain servisleriyle kurup Supabase/PostgreSQL üzerinde kullanıcı sahipliği ve senkronizasyon kurallarıyla merkezileştirdim; platform dağıtımını Cloudflare, Capacitor ve Tauri katmanlarına ayırdım.

/05

Neler yapıldı

Görev, not, alışkanlık, ritüel, kitaplık ve planlama domainlerinin ortak ürün mimarisi
Cloud-authoritative senkronizasyon ve oturum sürekliliği
Supabase RLS, RPC ve kullanıcı bazlı veri sahipliği
Google Calendar entegrasyonu
Markdown, wikilink ve bilgi grafiği katmanı
PWA, bildirimler, deep-link ve platform paketleme
Paddle / Adapty entitlement ve abonelik modeli

/06

Sistem mimarisi

Platform mimarisi

React / TypeScript
Web → Cloudflare
Android → Capacitor
iOS → Capacitor foundation
Windows → Tauri / Rust
Domain Services
Supabase / PostgreSQL
Auth · RLS · RPC · Storage

/07

Teknik yığın

Frontend

React · TypeScript · Vite · React Router · TanStack Query · Zustand · Radix UI · Milkdown · Framer Motion

Backend

Supabase · PostgreSQL · RLS · RPC

Altyapı

Cloudflare · R2

Platform

Capacitor · Tauri · Rust

Gözlem / Test

Sentry · PostHog · Amplitude · Vitest · Playwright

Ödeme

Paddle · Adapty

/08

Önemli mühendislik kararları

Cloud'u otorite kabul edip istemcileri senkronize yüzeyler olarak tasarlamak
Android ve Windows için ayrı ürün kod tabanları yerine ortak web katmanını paketlemek
Veri sahipliğini yalnızca UI mantığına değil RLS seviyesine yazmak
Yeni modülleri bağımsız adalar yerine ortak günlük komuta merkezi modeline bağlamak

/09

Kod / mimari örnekleri

Ürün mimarisi özetiTS

01const ordovia = {
02  frontend: ["React", "TypeScript", "Vite"],
03  data: ["Supabase", "PostgreSQL", "RLS"],
04  edge: ["Cloudflare", "R2"],
05  mobile: "Capacitor",
06  desktop: "Tauri",
07  model: "cloud-authoritative",
08} satisfies ProductArchitecture;

/10

Veri akışı

User action
Domain service
Optimistic UI / query cache
Supabase RPC / tables
RLS + persistence
Realtime / refresh
Synchronized clients

/11

Zorluklar ve kısıtlar

Çok sayıda domain arasında senkronizasyon ve kimlik tutarlılığı
Web, Android ve Windows sürümlerinde aynı davranışı korumak
Ürün büyürken performans, entitlement ve auth regresyonlarını sınırlandırmak

/12

Sonuç / mevcut durum

Ordovia bugün web ve Android'de yayınlanan, Windows dağıtım hattı bulunan ve iOS temeli hazırlanmış yaşayan bir ürün. Case study, tek tek özelliklerden çok bu büyüyen sistemin mimarisini gösteriyor.

/13

Mühendislik çıkarımları

Çok modüllü ürünlerde en değerli katman ekranlar değil domain sınırlarıdır.
Senkronizasyon davranışı ürün sonradan büyüyünce eklenmemeli; mimarinin parçası olmalı.
Tek kod tabanı ancak platform farkları bilinçli sınırlandırılırsa kaldıraç sağlar.

Ürünü gör

Ordovia