Alphazed, 50’den fazla ülkede 95.000’den fazla öğrenciye hizmet veren tüm backend sistemini Serverless Framework ile AWS Lambda üzerinde çalıştırıyor. Mimari, API Gateway arkasında Lambda üzerinde Flask, RDS üzerinde MySQL 8, içerik dağıtımı için S3 ve öğrenme sonuçlarını takip eden özel bir analiz havuzunu (SQS → Kinesis Firehose → S3 → Glue → Athena) kullanıyor. İnce Lambda handler’ları soğuk başlatma gecikmesini optimize ediyor ve sistem, tek bir kod tabanından 7’den fazla uygulamayı çalışma zamanı yapılandırmasıyla sunuyor.
EdTech için Neden Serverless?
Eğitsel uygulamaların kullanım desenleri öngörülemezdir:
- Hafta içi sabahları: Ebeveynler çocuğunu okula göndermeden önce uygulamayı indirir (trafik artışı)
- Hafta içi öğleden sonraları: Okul sonrası pratik seansları (sürekli yük)
- Hafta sonları: Yoğun maraton oturumları (normal yükün 2-3 katı)
- Ramazan’da: Akşam kullanımı patlaması (aile Kuran oturumları)
- Okul tatilleri: Tamamen farklı kullanım düzenleri
Serverless avantajları:
- Kullanım başına ödeme: Yalnızca kullandığınız kadar ödersiniz. 10 kullanıcı varsa 10 çağrı için ödeme yapılır. 100.000 kullanıcı anlık artışta anında ölçeklenir.
- Sık erişilen uç noktalar için sıfır soğuk başlangıç: Sık çağrılan uç noktalar için "her zaman sıcak" Lambda katmanları kullanılır.
- Otomatik ölçeklendirme: 10 veya 10.000 eşzamanlı kullanıcıyı altyapı değişikliği olmadan destekler.
- Sıfır sunucu bakımı: Ekip müfredat ve yapay zekaya odaklanır, Kubernetes ya da yük dengeleyici yönetmez.
Mimari Derinlemesine İnceleme
API Gateway → Lambda → RDS
[İstemci Uygulaması] (iOS, Android, Web)
↓
[API Gateway] (HTTP yönlendirme, hız limitleme)
↓
[Lambda Handler’lar] (Flask uygulaması, 512MB bellek, 28s zaman aşımı)
├── Uygulama rotaları: /app/* (mobil uç noktalar)
├── Kullanıcı rotaları: /user/* (kimlik doğrulamalı uç noktalar)
└── Yönetici rotaları: /boss/* (yönetici paneli)
↓
[MySQL 8 on RDS] (kalıcı veri)
↓
[Cevap] (JSON formatında istemciye dönüş)
Hız İçin İnce Lambda
Çoğu Lambda kasıtlı olarak minimal tutulmuştur:
# İnce handler (~100KB)
import json
import pymysql
def get_user_progress(event, context):
user_id = event['pathParameters']['user_id']
# Doğrudan veritabanı bağlantısı (ORM yükü yok)
conn = pymysql.connect(host='rds.aws.com', user='app', password='...', database='amal')
cursor = conn.cursor()
cursor.execute(
'SELECT concept_id, accuracy FROM user_memory WHERE user_id = %s',
(user_id,)
)
rows = cursor.fetchall()
conn.close()
return {
'statusCode': 200,
'body': json.dumps([{'concept': r[0], 'accuracy': r[1]} for r in rows])
}
Flask import edilmez, SQLAlchemy ORM ve middleware yoktur. Sonuç: Tam Flask uygulamasının 5-10 saniyesi yerine ~500ms soğuk başlangıç.
İçerik oluşturma ve analiz işleme gibi ağır uç noktalar tam Flask kullanır:
# Ağır handler (~30MB Flask, SQLAlchemy, numpy ile)
from flask import Flask, jsonify
from models import UserMemory
import numpy as np
app = Flask(name)
@app.route('/content_duo/generate', methods=['POST'])
def generate_content_duo():
# ORM gerektiren karmaşık mantık
user = UserMemory.query.filter_by(user_id=request.json['user_id']).first()
# ... kişiselleştirilmiş oturum oluşturma ...
return jsonify(session_data)
Takas: Soğuk başlangıçlar daha yavaş fakat bu uç noktalar daha nadiren çağrılır.
Uygulama Başına Tablo Önekleri
Tek bir RDS örneği 7’den fazla uygulamaya veritabanı düzeyinde izolasyonla hizmet verir:
-- Amal uygulaması
CREATE TABLE amal_users (...)
CREATE TABLE amal_content_bytes (...)
CREATE TABLE amal_user_memory (...)
-- Thurayya uygulaması
CREATE TABLE thurayya_users (...)
CREATE TABLE thurayya_content_bytes (...)
CREATE TABLE thurayya_user_memory (...)
-- Diğer uygulamalar: qais_, kidelite_, vb.
Deploy sırasında, `APP_NAME` çevresel değişkeni öneki seçer:
app_name = os.getenv('APP_NAME', 'amal') # 'amal', 'thurayya', 'qais', vb.
Sorgular dinamik önek kullanır
table_name = f'{app_name}_users'
cursor.execute(f'SELECT * FROM {table_name} WHERE id = %s', (user_id,))
Analiz Havuzu
Sorun: Analiz için doğrudan veritabanı sorguları üretim performansını yavaşlatır. Raporlar tablo kilitlerine yol açar.
Çözüm: Asenkron analiz iş akışı
[Mobil Uygulama]
↓ (etkinlik gönderir)
[API Uç Noktası] → [SQS Kuyruğu] (asenkron)
↓ (uygulamaya hemen cevap verir)
↓ (analizi beklemez)
[Kinesis Firehose] (her 5 dakikada veya 100MB dolunca toplu gönderir)
↓
[S3] (bölümlenmiş: s3://analytics-lake/amal/2026/03/28/events.parquet)
↓
[AWS Glue] (S3’ü tarar, şema çıkarır)
↓
[Athena] (Presto motoru ile SQL sorguları)
↓
[Dashboard] (gerçek zamanlı içgörüler sunar)
Dead Letter Queue (DLQ) Deseni
Analiz başarısız olursa:
SQS → [Firehose başarısız]
↓
[DLQ başarısız mesajları alır]
↓
[Operasyonlara uyarı gönderilir]
↓
[Üretim API’si etkilenmez]
Analiz, kullanıcı isteklerini engellemez. Çocuklar, analiz hattı arızalı olsa bile öğrenmeye devam eder.
Maliyet Optimizasyon Stratejileri
- İnce Lambda’lar yüksek frekanslı uç noktalar için:
Ortalama mobil uygulama oturumu 10-20 API çağrısı yapar. 95.000 aktif kullanıcı × günde 3 oturum × 15 çağrı = 4.275.000 çağrı/gün. Lambda maliyeti çağrı başına $0.0000002 ise günlük maliyet $0.86. Soğuk başlangıç süresini 10 saniye azaltmak aylık ~$500 tasarruf sağlar. - RDS Ayrılmış Örnekler:
3 yıl taahhüt ile ~%60 indirim sağlar. db.r6i.xlarge (4 vCPU, 32GB RAM): Ayrılmış $2,800/ay, on-demand $6,500/ay. Yıllık tasarruf ~$50.000 - Önbellekleme:
Sık erişilen veriler ElastiCache (Redis) içinde önbelleğe alınır, RDS sorguları %70 azalır. Önbellek maliyeti $800/ay, RDS tasarrufu $2.000/ay
Tek Kod Tabanından 7+ Uygulama Sunma
| Uygulama | Önek | DB Tabloları | Lambda Yığını | Durum |
|---|---|---|---|---|
| Amal | amal_ | 40+ tablo | Paylaşımlı | Üretim |
| Thurayya | thurayya_ | 40+ tablo | Paylaşımlı | Üretim |
| Qais | qais_ | 35+ tablo | Paylaşımlı | Beta |
| KidElite | kidelite_ | 40+ tablo | Paylaşımlı | Üretim |
| Alphazed School | school_ | 50+ tablo | Paylaşımlı | Beta |
| Alphazed Montessori | montessori_ | 45+ tablo | Paylaşımlı | Dahili |
Tek backend, tek deployment pipeline, aynı anda 6 uygulama. Yeni uygulama lansmanı haftalar sürer, aylar değil.
SSS
S: Lambda'nın 15 dakikalık zaman aşımı limiti yok mu?
A: Lambda'nın maksimum 15 dakikalık zaman aşımı vardır, ancak uzun çalışan istekler nadirdir. Ağır işler (içerik üretimi, büyük dışa aktarımlar) SQS + Step Functions ile asenkron yürütülür.
S: Veritabanı çökerse ne olur?
A: RDS Çoklu AZ failover yapısı (birincil + yedek replikalı). Failover otomatik ve yaklaşık 60 saniye sürer. İstemciler kısa bir kesinti yaşar, ancak hızlı iyileşme olur.
S: Durumsuz Lambda ile veritabanı bağlantı havuzlama nasıl yapılır?
A: Her Lambda örneği bağlantı havuzunu sürdürür ve sıcak çağrılar arasında yeniden kullanır. Soğuk başlangıç yeni bağlantılar açar. RDS Proxy Lambda ile RDS arasındaki bağlantı sınırlarını yönetir.
