Most SaaS products that fail after 12 months don't die from lack of market. They die from an architecture that can't support growth, technical debt that paralyzes iteration speed, or a security incident that destroys client trust in 48 hours.
This article covers the architectural decisions that separate a SaaS that holds at enterprise scale from a prototype that holds up to the first 1,000 users. These are not theoretical abstractions — they are patterns observed across 40+ SaaS projects over 21 years.
La plupart des SaaS qui échouent après 12 mois ne meurent pas d'un manque de marché. Ils meurent d'une architecture qui ne supporte pas la croissance, d'une dette technique qui paralyse la vitesse d'itération, ou d'un incident de sécurité qui détruit la confiance client en 48 heures.
Cet article couvre les décisions d'architecture qui distinguent un SaaS qui tient à l'échelle enterprise d'un prototype qui tient jusqu'aux premiers 1,000 utilisateurs. Ce ne sont pas des abstractions théoriques — ce sont des patterns observés sur plus de 40 projets SaaS en 21 ans.
غالبية المشاريع SaaS اللي كيفشلو بعد 12 شهر ما كيموتوش من نقص السوق. كيموتو من معمارية ما كتسحبش النمو، دين تقني (technical debt) كيعيق سرعة التطوير، ولا حادثة أمنية كتخسر ثقة العملاء فـ 48 ساعة.
هاد المقال كيغطي القرارات المعمارية اللي كيفرقو بين SaaS كيصمد فالـ enterprise scale وبين بروتوتيب كيوقف عند أول 1,000 مستعمل. ماشي كلام نظري — هادو patterns شفناهم فـ 40+ مشروع SaaS على مدى 21 عام.
Fatal Mistake #1: Monolith-First Without an Exit Strategy
Starting with a monolith is not wrong. Staying with an unplanned monolith past product-market fit is.
The problem is not the monolith itself — it's that most teams treat it as the permanent architecture rather than a bootstrap. When you hit 50+ engineers and 500+ customers, a monolith without clear module boundaries becomes a deployment bottleneck, a testing nightmare, and an onboarding obstacle simultaneously.
The Modular Monolith: The Architecture Nobody Talks About
You do not need microservices at seed stage. You need a modular monolith — a single deployable unit with clean internal module boundaries that map to business domains. Each module has its own:
- Database schema namespace (not a separate DB — the same DB, but isolated tables with no cross-module foreign keys)
- Public API contract (other modules communicate only through defined interfaces, never direct DB queries across modules)
- Independent test suite (can be tested in isolation without spinning up the entire application)
When you need to extract a module into a microservice — because it has independent scaling requirements or a separate deployment cadence — the boundary is already defined. The extraction is a deployment change, not an architectural rewrite.
Rewiring a spaghetti monolith into services typically costs 6-18 months of engineering time and introduces a 30-40% regression risk. Building a modular monolith from the start costs 15-20% more upfront and saves an order of magnitude more at scale. We have done both. The modular approach wins every time.
Erreur fatale #1 : Le monolithe sans stratégie de sortie
Commencer par un monolithe n'est pas une erreur. Y rester sans plan après le product-market fit en est une.
Le problème n'est pas le monolithe lui-même — c'est que la plupart des équipes le traitent comme une architecture permanente plutôt que comme un démarrage. Quand vous atteignez 50+ ingénieurs et 500+ clients, un monolithe sans frontières de modules claires devient simultanément un goulot d'étranglement de déploiement, un cauchemar de tests, et un obstacle à l'onboarding.
Le Modular Monolith : l'architecture dont personne ne parle
Vous n'avez pas besoin de microservices au stade seed. Vous avez besoin d'un modular monolith — une seule unité déployable avec des frontières internes propres qui correspondent aux domaines métier. Chaque module a :
- Son propre namespace de schéma de base de données (pas une DB séparée — la même DB, mais des tables isolées sans clés étrangères inter-modules)
- Son contrat d'API publique (les autres modules communiquent uniquement via des interfaces définies, jamais des requêtes DB directes inter-modules)
- Sa propre suite de tests indépendante (testable en isolation sans démarrer toute l'application)
Quand vous devez extraire un module en microservice — parce qu'il a des besoins de scaling indépendants ou une cadence de déploiement séparée — la frontière est déjà définie. L'extraction est un changement de déploiement, pas une réécriture architecturale.
Réécrire un monolithe spaghetti en services coûte typiquement 6-18 mois de temps d'ingénierie et introduit un risque de régression de 30-40%. Construire un modular monolith dès le départ coûte 15-20% de plus en amont et fait économiser un ordre de grandeur à l'échelle. Nous avons fait les deux. L'approche modulaire gagne à chaque fois.
الغلطة القاتلة #1 : المونوليث بلا استراتيجية للخروج
تبدا بمونوليث ماشي غلط. تبقى فيه بلا تخطيط من بعد الـ PMF، هاديك هي الغلطة.
المشكل ماشي فالمونوليث، المشكل أن غالبية الفرق كيتعاملو معاه بحال هو المعمارية الدائمة، ماشي بحال بداية. ملي توصل لـ 50+ مهندس و500+ عميل، المونوليث بلا حدود واضحة كيولي bottleneck فالنشر، كابوس فالاختبارات، وعقبة فالـ onboarding فنفس الوقت.
الـ Modular Monolith : المعمارية اللي حتى حد ما كيهضر عليها
ما خاصكش microservices فمرحلة seed. خاصك modular monolith — وحدة وحدة قابلة للنشر، بحدود داخلية نظيفة كيتطابقو مع domains ديال البيزنس. كل module عندو :
- namespace ديالو فالـ schema (ماشي DB منفصلة — نفس الـ DB، ولكن جداول معزولة بلا foreign keys بين modules)
- API contract عمومي (modules لخرين كيتواصلو فقط عبر interfaces محددة، ما كيدير حتى query مباشر للـ DB عبر modules)
- test suite مستقلة (يمكن تتختبر بوحدها بلا ما تخدم التطبيق كامل)
ملي تحتاج تخرج module لـ microservice — حيت عندو متطلبات scaling مستقلة أو cadence نشر مختلفة — الحدود راها معروفة. الخروج كيولي تغيير فالنشر، ماشي إعادة كتابة معمارية.
إعادة كتابة مونوليث spaghetti لـ services غالباً كتكلف 6-18 شهر من الهندسة، وكتجيب 30-40% خطر regression. بناء modular monolith من البداية كيكلف 15-20% زيادة فالبداية، وكيوفر بزاف فالـ scale. درنا الزوج. الـ modular كيربح كل مرة.
Fatal Mistake #2: Database Schema Designed for Today, Not for Tomorrow
The most expensive technical debt in a SaaS is almost always in the database schema. Not the code — the schema. Code can be refactored progressively. Schema migrations on a 10M-row production table, under live traffic, with zero downtime, are a different category of problem.
The five schema decisions that create irreversible debt
- Using auto-increment integers as external IDs. When you add a second database (read replica, sharding, multi-tenant isolation), integer IDs create collision and ordering problems. Use UUIDs v7 (time-ordered) from day one.
- No soft delete. Cascade hard deletes in a SaaS with audit requirements (finance, healthcare, government) are a compliance violation. Every entity table needs
deleted_atanddeleted_byfrom the start. - Storing tenant data in a shared schema without row-level isolation. Adding tenant isolation to a shared schema at scale requires touching every single query. Row-Level Security (PostgreSQL RLS) costs 2 hours to configure upfront and saves months later.
- No versioning on configuration or rule tables. When a client asks "what were my pricing rules on March 15th?", you need an event-sourced or versioned table. Retrofitting this at year 2 is a major project.
- JSON blobs for structured data. Using JSONB for schema flexibility is a legitimate choice. Using it as a substitute for proper normalization because "the schema might change" is accumulated debt. Define your schema. It will change less than you think.
Erreur fatale #2 : Schéma de base conçu pour aujourd'hui, pas pour demain
La dette technique la plus coûteuse dans un SaaS est presque toujours dans le schéma de base de données. Pas le code — le schéma. Le code peut être refactoré progressivement. Les migrations de schéma sur une table de production à 10M lignes, sous trafic réel, avec zéro downtime, sont d'une autre catégorie de problème.
Les cinq décisions de schéma qui créent une dette irréversible
- Utiliser des entiers auto-incrémentés comme IDs externes. Quand vous ajoutez une seconde DB (read replica, sharding, isolation multi-tenant), les IDs entiers créent des problèmes de collision et d'ordonnancement. Utilisez des UUIDs v7 (ordonnés par le temps) dès le jour un.
- Pas de soft delete. Les suppressions cascadées dans un SaaS avec exigences d'audit (finance, santé, gouvernement) sont une violation de conformité. Chaque table d'entité a besoin de
deleted_atetdeleted_bydès le départ. - Stocker les données tenant dans un schéma partagé sans isolation row-level. Ajouter l'isolation tenant à un schéma partagé à l'échelle nécessite de toucher chaque requête. Le Row-Level Security (PostgreSQL RLS) coûte 2 heures à configurer en amont et fait économiser des mois plus tard.
- Pas de versioning sur les tables de configuration ou de règles. Quand un client demande « quelles étaient mes règles tarifaires le 15 mars ? », vous avez besoin d'une table event-sourced ou versionnée. Rajouter ça en année 2 est un projet majeur.
- Blobs JSON pour données structurées. Utiliser JSONB pour la flexibilité du schéma est un choix légitime. L'utiliser comme substitut à une normalisation correcte parce que « le schéma pourrait changer » est de la dette accumulée. Définissez votre schéma. Il changera moins que vous pensez.
الغلطة القاتلة #2 : schema مصمم لليوم، ماشي لغدا
الدين التقني الأغلى فـ SaaS غالباً كيكون فالـ database schema. ماشي فالكود — فالـ schema. الكود يمكن يتفاكتر شوية بشوية. ولكن migrations فجدول production فيه 10M صف، تحت traffic حي، بزيرو downtime، هادي مشكلة من نوع آخر.
الخمس قرارات فالـ schema اللي كيخلقو دين ما يمكنش يتفك
- تستعمل integers auto-increment بحال IDs خارجية. ملي تزيد database ثانية (read replica، sharding، multi-tenant)، الـ integer IDs كيخلقو مشاكل ديال collision و ordering. استعمل UUIDs v7 (مرتبة بالوقت) من اليوم الأول.
- بلا soft delete. الـ hard deletes cascade فـ SaaS فيه متطلبات audit (مالية، صحة، حكومة) هي مخالفة للـ compliance. كل جدول entity خاصو
deleted_atوdeleted_byمن البداية. - تخزن data ديال tenants فـ schema مشترك بلا isolation row-level. تزيد tenant isolation فـ schema مشترك فالـ scale كيخصك تمس كل query. Row-Level Security (PostgreSQL RLS) كيكلف 2 سوايع فالبداية وكيوفرلك شهور من بعد.
- بلا versioning فجداول الـ configuration أو rules. ملي عميل كيسولك «شنو كانو قواعد التسعير ديالي فـ 15 مارس؟»، كتحتاج جدول event-sourced أو versioned. تزيدو فالعام 2 مشروع كبير.
- JSON blobs للبيانات structured. تستعمل JSONB للمرونة فالـ schema ماشي مشكل. تستعملها بحال بديل للـ normalization حيت «schema يمكن يتبدل» هادا دين كيتراكم. عرف schema ديالك. غادي يتبدل قل مما كتظن.
Fatal Mistake #3: Security Added After Launch
Security by design is not about adding a firewall. It is about making secure behavior the default at every layer — authentication, authorization, data access, logging, secrets management — before you write the first business logic line.
The non-negotiable security baseline for a production SaaS
- Authentication: Never build your own. Use a managed identity provider (AWS Cognito, Auth0, Keycloak on-prem for sensitive deployments). If you are handling Moroccan citizen data, the auth layer must be hosted within your sovereign infrastructure perimeter.
- Authorization: Implement Attribute-Based Access Control (ABAC) from day one, not Role-Based. RBAC breaks when you add fine-grained resource permissions (and you will). ABAC gives you the flexibility without the refactor.
- Secrets management: No credentials in environment variables directly. Use AWS Secrets Manager or HashiCorp Vault. Rotate secrets automatically. Audit access to secrets. This is a 2-hour setup that has prevented breaches we have seen cost companies millions of dirhams.
- Transport security: TLS everywhere, including service-to-service internal traffic. mTLS for microservice communication if you are handling sensitive data categories. Do not assume your VPC is a trust boundary.
- Input validation: All external input validated and sanitized before it touches the database layer. Parameterized queries everywhere. This is table stakes, not advanced security — yet we still find SQL injection vulnerabilities in SaaS code reviews in 2026.
Law 09-08 Article 24 requires data controllers to implement "appropriate technical and organizational measures" to protect personal data. A SaaS that stores customer data without encryption at rest, without access logging, or without a defined incident response procedure is in breach — regardless of whether an incident has occurred. CNDP can fine on the basis of inadequate controls, not just actual breaches.
Erreur fatale #3 : Sécurité ajoutée après le lancement
La sécurité by design ne consiste pas à ajouter un firewall. Il s'agit de faire du comportement sécurisé le défaut à chaque couche — authentification, autorisation, accès aux données, logging, gestion des secrets — avant d'écrire la première ligne de logique métier.
La baseline sécurité non négociable pour un SaaS en production
- Authentification : Ne la construisez jamais vous-même. Utilisez un identity provider managé (AWS Cognito, Auth0, Keycloak on-prem pour déploiements sensibles). Si vous manipulez des données de citoyens marocains, la couche d'auth doit être hébergée dans votre périmètre d'infrastructure souveraine.
- Autorisation : Implémentez l'Attribute-Based Access Control (ABAC) dès le jour un, pas le Role-Based. RBAC casse quand vous ajoutez des permissions fines sur les ressources (et vous le ferez). ABAC vous donne la flexibilité sans le refactor.
- Gestion des secrets : Pas de credentials directement dans les variables d'environnement. Utilisez AWS Secrets Manager ou HashiCorp Vault. Rotation automatique des secrets. Audit des accès aux secrets. C'est un setup de 2 heures qui a évité des breaches qui ont coûté des millions de dirhams à des entreprises que nous avons vues.
- Sécurité du transport : TLS partout, y compris le trafic interne service-à-service. mTLS pour la communication microservice si vous manipulez des catégories de données sensibles. Ne supposez pas que votre VPC est une frontière de confiance.
- Validation des entrées : Toute entrée externe validée et assainie avant qu'elle touche la couche database. Requêtes paramétrées partout. C'est du basique, pas de la sécurité avancée — pourtant on trouve encore des vulnérabilités SQL injection dans les revues de code SaaS en 2026.
L'article 24 de la loi 09-08 exige que les responsables de traitement implémentent des « mesures techniques et organisationnelles appropriées » pour protéger les données personnelles. Un SaaS qui stocke des données clients sans chiffrement at rest, sans logging des accès, ou sans procédure de réponse aux incidents définie est en infraction — qu'un incident ait eu lieu ou non. La CNDP peut sanctionner sur la base de contrôles inadéquats, pas seulement de breaches réels.
الغلطة القاتلة #3 : الأمن مزاد من بعد الإطلاق
الـ security by design ماشي معناه تزيد firewall. معناه أن السلوك الآمن يكون هو الدفولت فكل layer — authentication، authorization، access ديال data، logging، secrets — قبل ما تكتب أول سطر من business logic.
الحد الأدنى ديال الأمن اللي ما يمكنش يتفاوض عليه فـ SaaS production
- Authentication : عمرك ما تبنيه بيدك. استعمل identity provider managed (AWS Cognito، Auth0، Keycloak on-prem للنشر الحساس). إلا كنتي كتعالج data ديال مواطنين مغاربة، الـ auth خاصها تكون مستضافة فالبنية التحتية السيادية ديالك.
- Authorization : دير Attribute-Based Access Control (ABAC) من اليوم الأول، ماشي Role-Based. RBAC كيتكسر ملي تزيد permissions دقيقة (وغادي تزيدهم). ABAC كيعطيك المرونة بلا refactor.
- Secrets management : ما تخليش credentials فـ environment variables مباشرة. استعمل AWS Secrets Manager ولا HashiCorp Vault. دير rotation أوتوماتيكي. دير audit للوصول. هادا setup ديال 2 سوايع، شفناه كيوقف breaches اللي كلفو شركات ملايين الدراهم.
- Transport security : TLS فكل بلاصة، حتى الـ traffic الداخلي بين services. mTLS للتواصل بين microservices إلا كنتي كتعالج data حساسة. ما تظنش أن VPC ديالك حد ثقة.
- Input validation : كل input خارجي خاصو يتحقق ويتنقا قبل ما يوصل لـ database. Parameterized queries فكل بلاصة. هادا أساسي ماشي متقدم — ولكن حتى دابا فـ 2026 كنلقاو SQL injection فـ code reviews ديال SaaS.
القانون 09-08 المادة 24 كيطالب المسؤولين على البيانات يديرو «تدابير تقنية وتنظيمية مناسبة» لحماية البيانات الشخصية. SaaS اللي كيخزن data ديال العملاء بلا encryption at rest، بلا access logging، أو بلا procedure مخصصة للحوادث، راه فمخالفة — حتى إلا ما وقع حتى incident. CNDP يقدر يعاقب على أساس ضعف الـ controls، ماشي غير على breaches فعلية.
The Hybrid Infrastructure Model for Moroccan SaaS
The architecture question for most Moroccan SaaS is not "cloud vs. on-premise" — it's "which workloads go where". A hybrid model is almost always the right answer:
What belongs on AWS Casablanca Local Zones
- User-facing APIs and web application (latency-sensitive, needs to be close to Moroccan users)
- AI inference endpoints (sovereign LLM, vision models)
- Real-time features (WebSocket servers, presence, notifications)
- Primary database (with Multi-AZ for failover)
What belongs on AWS eu-west-1 (or us-east-1)
- Batch processing workloads (nightly ML training, report generation)
- Cold storage and archival (S3 Glacier for audit logs)
- CI/CD pipeline infrastructure
- Non-sensitive third-party integrations
What might stay on-premise
- Highly sensitive data categories (medical records, financial instruments) where a client contract requires on-premise processing
- Real-time edge processing where cloud round-trip latency is unacceptable (industrial vision, embedded systems integration)
Le modèle d'infrastructure hybride pour le SaaS marocain
La question d'architecture pour la plupart des SaaS marocains n'est pas « cloud vs. on-premise » — c'est « quelles workloads vont où ». Un modèle hybride est presque toujours la bonne réponse :
Ce qui appartient à AWS Casablanca Local Zones
- APIs user-facing et application web (sensible à la latence, doit être proche des utilisateurs marocains)
- Endpoints d'inférence IA (LLM souverain, modèles de vision)
- Fonctionnalités temps réel (serveurs WebSocket, présence, notifications)
- Base de données primaire (avec Multi-AZ pour le failover)
Ce qui appartient à AWS eu-west-1 (ou us-east-1)
- Workloads de traitement batch (entraînement ML nocturne, génération de rapports)
- Stockage froid et archivage (S3 Glacier pour les logs d'audit)
- Infrastructure de pipeline CI/CD
- Intégrations tierces non sensibles
Ce qui peut rester on-premise
- Catégories de données hautement sensibles (dossiers médicaux, instruments financiers) où un contrat client exige un traitement on-premise
- Traitement edge temps réel où la latence aller-retour cloud est inacceptable (vision industrielle, intégration de systèmes embarqués)
نموذج البنية التحتية الهجينة للـ SaaS المغربي
سؤال المعمارية لغالبية الـ SaaS المغاربة ماشي «cloud ولا on-premise» — هو «أي workload فين كيمشي». النموذج الهجين غالباً هو الجواب الصحيح :
اللي خاصو يمشي لـ AWS Casablanca Local Zones
- الـ APIs user-facing والـ web application (حساسة للـ latency، خاصها تكون قريبة من المستعملين المغاربة)
- Endpoints ديال AI inference (LLM سيادي، vision models)
- Features ديال real-time (WebSocket servers، presence، notifications)
- الـ database الرئيسية (مع Multi-AZ للـ failover)
اللي خاصو يمشي لـ AWS eu-west-1 (ولا us-east-1)
- Workloads ديال batch processing (تدريب ML بالليل، توليد reports)
- Cold storage و archival (S3 Glacier للـ audit logs)
- Infrastructure ديال CI/CD pipeline
- Integrations مع أطراف ثالثة ماشي حساسة
اللي يمكن يبقى on-premise
- أنواع data حساسة بزاف (سجلات طبية، أدوات مالية) فين عقد العميل كيطالب معالجة on-premise
- Edge processing real-time فين latency ديال الـ cloud غير مقبولة (vision صناعي، integration ديال embedded systems)
The Technical Debt Measurement Framework
Technical debt is not just messy code. It is any architectural decision that reduces your future optionality. To manage it, you need to measure it.
We use four metrics in quarterly architecture reviews:
- Deployment frequency: How many times per week can you deploy to production? If the answer is "once a week because it's too risky", you have a structural debt problem, not a discipline problem.
- Mean time to restore (MTTR): When production breaks, how long to recover? If MTTR > 2 hours, you lack observability.
- Change failure rate: What percentage of deployments cause a production incident? Above 5% indicates insufficient test coverage or missing feature flags.
- Cognitive load per module: How long does it take a new engineer to make a change in a given module without breaking something? If the answer is "more than a day", the module boundary is wrong.
Technical debt is a tax. Like all taxes, a small, predictable, managed amount is acceptable. An unmanaged accumulation becomes confiscatory — it takes more than 100% of your engineering capacity just to stay in place.
Le framework de mesure de la dette technique
La dette technique n'est pas juste du code en désordre. C'est toute décision architecturale qui réduit votre optionalité future. Pour la gérer, vous devez la mesurer.
Nous utilisons quatre métriques dans les revues d'architecture trimestrielles :
- Fréquence de déploiement : Combien de fois par semaine pouvez-vous déployer en production ? Si la réponse est « une fois par semaine parce que c'est trop risqué », vous avez un problème de dette structurelle, pas de discipline.
- Mean time to restore (MTTR) : Quand la production casse, combien de temps pour récupérer ? Si MTTR > 2 heures, vous manquez d'observabilité.
- Taux d'échec des changements : Quel pourcentage de déploiements cause un incident en production ? Au-dessus de 5%, cela indique une couverture de tests insuffisante ou des feature flags manquants.
- Charge cognitive par module : Combien de temps un nouvel ingénieur met-il pour faire un changement dans un module donné sans casser quelque chose ? Si la réponse est « plus d'une journée », la frontière du module est mauvaise.
La dette technique est une taxe. Comme toutes les taxes, un montant petit, prévisible et géré est acceptable. Une accumulation non gérée devient confiscatoire — elle prend plus de 100% de votre capacité d'ingénierie juste pour rester en place.
إطار قياس الدين التقني
الدين التقني ماشي غير كود مخربق. هو أي قرار معماري كينقص من الخيارات المستقبلية ديالك. باش تدبرو، خاصك تقيسو.
كنستعملو 4 metrics فالـ reviews المعمارية كل ربع :
- Deployment frequency : شحال من مرة فالأسبوع تقدر تدير deploy للـ production؟ إلا الجواب «مرة فالأسبوع حيت خطير»، عندك مشكل دين هيكلي، ماشي مشكل انضباط.
- Mean time to restore (MTTR) : ملي production كيتكسر، شحال كتاخذ باش ترجع؟ إلا MTTR > 2 سوايع، عندك نقص فالـ observability.
- Change failure rate : أش من نسبة من الـ deployments كتسبب incident فالـ production؟ فوق 5% كيدل على نقص فالـ tests ولا feature flags ناقصة.
- Cognitive load لكل module : شحال كيخذ مهندس جديد باش يدير تغيير فـ module بلا ما يكسر شي حاجة؟ إلا الجواب «أكثر من نهار»، الحدود ديال الـ module خايبة.
الدين التقني هو ضريبة. بحال جميع الضرائب، مبلغ صغير ومتوقع ومدبر مقبول. التراكم بلا تدبير كيولي مصادرة — كياخذ أكثر من 100% من capacity الهندسة ديالك غير باش تبقى فبلاصتك.
The Scalability Decision Points: When to Upgrade Each Layer
Premature optimization is waste. But underprepared scaling is crisis. The decision to upgrade each layer should be driven by metrics, not by milestone or competitor pressure.
- Database read replicas: When read queries exceed 70% of total DB load, or when read p99 latency exceeds 200ms. Not before.
- Caching layer (Redis/ElastiCache): When you identify queries that return identical results for identical inputs and run more than 100×/hour. Cache these first; optimize the rest.
- Service extraction: When a module has a distinct scaling requirement from the main application, or when the deployment of unrelated features blocks that module's deployment.
- CDN for assets: Day one. There is no reason not to put CloudFront in front of your static assets from launch. The cost is negligible; the latency gain for geographically distributed users is immediate.
- Job queue (SQS/BullMQ): When a user action triggers work that takes >200ms and the user does not need the result synchronously. Do not do synchronous work in the request cycle that can be deferred.
Les points de décision de scalabilité : quand upgrader chaque couche
L'optimisation prématurée est du gaspillage. Mais le scaling mal préparé est une crise. La décision d'upgrader chaque couche doit être pilotée par les métriques, pas par un jalon ou la pression d'un concurrent.
- Read replicas de database : Quand les requêtes en lecture dépassent 70% de la charge totale DB, ou quand la latence p99 en lecture dépasse 200ms. Pas avant.
- Couche de cache (Redis/ElastiCache) : Quand vous identifiez des requêtes qui retournent des résultats identiques pour des entrées identiques et tournent plus de 100×/heure. Cachez celles-ci d'abord ; optimisez le reste.
- Extraction de service : Quand un module a un besoin de scaling distinct de l'application principale, ou quand le déploiement de features non liées bloque le déploiement de ce module.
- CDN pour les assets : Jour un. Il n'y a aucune raison de ne pas mettre CloudFront devant vos assets statiques dès le lancement. Le coût est négligeable ; le gain de latence pour des utilisateurs géographiquement distribués est immédiat.
- Job queue (SQS/BullMQ) : Quand une action utilisateur déclenche un travail qui prend >200ms et que l'utilisateur n'a pas besoin du résultat synchroniquement. Ne faites pas de travail synchrone dans le cycle de requête qui peut être différé.
نقط القرار ديال الـ scalability : إمتى تعمل upgrade لكل layer
الـ optimization السابقة هي ضياع. ولكن الـ scaling بلا تحضير هو أزمة. القرار باش تعمل upgrade لكل layer خاصو يكون مبني على metrics، ماشي على milestones ولا ضغط ديال المنافسين.
- Read replicas ديال الـ database : ملي queries ديال القراءة كيفوتو 70% من الحمولة الكلية ديال الـ DB، ولا ملي p99 latency فالقراءة كيفوت 200ms. ماشي قبل.
- Caching layer (Redis/ElastiCache) : ملي تكتشف queries كيرجعو نفس النتائج لنفس inputs وكيخدمو أكثر من 100×/سايعة. خبيهم فالأول ; optimizي الباقي.
- Service extraction : ملي module عندو متطلب scaling مختلف على التطبيق الرئيسي، ولا ملي نشر features ما عندهومش علاقة كيوقف نشر ديك module.
- CDN للـ assets : اليوم الأول. ما كاينش سبب باش ما تحطش CloudFront قدام assets static ديالك من البداية. التكلفة قليلة ; ربح الـ latency للمستعملين فبلدان مختلفة فوري.
- Job queue (SQS/BullMQ) : ملي action ديال user كيطلق خدمة كتاخذ >200ms والمستعمل ما خاصوش النتيجة فنفس الوقت. ما تديرش خدمة synchronous فدورة الـ request اللي يمكن تأخر.