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

CTX-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.

PRB-01

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ı.

ROL-01

Rolüm

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

SOL-01

Çö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.

BLD-01

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

ARC-01

Sistem mimarisi

Platform mimarisi

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

STK-01

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

DEC-01

Ö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

CODE-01

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;

FLOW-01

Veri akışı

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

RISK-01

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

OUT-01

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.

LRN-01

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.

OUT-LIVE / Ürünü gör

Ordovia

Ürünü gör