7 Architecture Decisions That Determine Whether Your SaaS Scales or Breaks

Architecture Is the Foundation You Cannot Easily Rebuild

Most SaaS failures are not product failures. They are architecture failures that show up six to eighteen months after launch, when the product has traction but the technical foundation cannot support what the business needs next.

The difficult truth about software architecture is that the decisions with the highest long-term impact are made when you know the least about your product. In the first weeks of development, you choose your multi-tenancy strategy, your API paradigm, your authentication model, and your deployment topology. These decisions are expensive to reverse. Some are effectively irreversible without a rewrite.

This is not an argument for over-engineering. It is an argument for making informed decisions about the seven architectural choices that will determine whether your SaaS scales gracefully or collapses under the weight of its own early shortcuts.

Each section below covers one decision, the options available, what goes wrong when you choose poorly, and what the right choice looks like at each stage of growth.

Decision 1: Multi-Tenancy Strategy

Multi-tenancy is the defining architectural characteristic of SaaS. Every customer (tenant) uses the same application, but their data must be isolated. How you achieve that isolation affects cost, performance, compliance posture, and operational complexity for the entire life of the product.

Option A: Shared Database with Tenant ID

Every table includes a tenant_id column. Every query includes a WHERE tenant_id = ? clause. All tenants share the same database, the same schema, and the same tables.

Advantages: Simplest to implement. Lowest infrastructure cost. Easiest to maintain — one schema migration updates all tenants simultaneously. Resource efficient because a single database connection pool serves everyone.

Disadvantages: A bug in query scoping can leak data between tenants. This is the most common and most dangerous failure mode. Performance isolation is limited — one tenant running expensive queries can degrade performance for all tenants. Backup and restore is all-or-nothing at the database level unless you build custom export tooling.

Mitigation strategies: Use row-level security (PostgreSQL RLS) to enforce tenant isolation at the database level, making accidental data leakage structurally impossible rather than relying on application-level query discipline. Implement tenant-aware query logging to detect cross-tenant access patterns. Use read replicas to isolate reporting queries from transactional workloads.

When to choose this: For 90% of SaaS products, this is the right starting point. It is the right choice when your tenants have similar data volumes, you are not in a heavily regulated industry, and your pricing model does not promise dedicated resources.

Option B: Schema-Per-Tenant

Each tenant gets their own database schema within a shared database server. The application routes queries to the correct schema based on the authenticated tenant.

Advantages: Stronger logical isolation than shared tables. Per-tenant backup and restore is straightforward. Schema-level access controls add a second layer of isolation beyond application logic. Easier to comply with data residency requirements when combined with multiple database servers.

Disadvantages: Schema migrations must be applied to every tenant schema individually. At 500 tenants, a migration that takes 2 seconds per schema takes 16 minutes total. Connection management becomes more complex. Monitoring requires per-schema metrics. Provisioning a new tenant requires schema creation rather than just inserting a row.

When to choose this: When your customers require demonstrable data isolation (healthcare, finance, legal), when you need per-tenant backup/restore capabilities, or when individual tenants have significantly different data volumes and you need to manage storage independently.

Option C: Database-Per-Tenant

Each tenant gets a completely separate database instance. The application maintains a tenant-to-database mapping and routes connections accordingly.

Advantages: Maximum isolation. Per-tenant performance guarantees. Complete independence for backup, restore, scaling, and even geographic placement. Simplest compliance story — each tenant’s data is physically separated.

Disadvantages: Dramatically higher infrastructure costs. At 100 tenants, you are managing 100 database instances. Connection pooling becomes a significant engineering challenge. Cross-tenant analytics (for your own business intelligence) requires a separate data pipeline that aggregates across databases. Onboarding a new tenant requires provisioning infrastructure, not just creating a record. Schema migrations require orchestration across all instances.

When to choose this: For enterprise SaaS where customers pay premium prices (€10,000+/month) and contractually require dedicated resources, or for products in regulated industries where physical data separation is a regulatory requirement.

What Goes Wrong When You Choose Poorly

Choosing shared database when you need isolation: You land an enterprise customer who requires SOC 2 compliance and dedicated data storage. You cannot deliver without re-architecting your entire data layer, which takes 3-6 months and puts your enterprise sales pipeline on hold.

Choosing database-per-tenant when you do not need it: You spend 4x more on infrastructure and 2x more on operational tooling. Your deployment pipeline is complex, your migrations are fragile, and your team spends 20% of their time on infrastructure management instead of product development. At 200 tenants with an average contract value of €200/month, the infrastructure overhead consumes most of your margin.

The Right Choice at Each Stage

• 0-100 tenants, pre-product-market fit: Shared database with row-level security. Focus every engineering hour on product, not infrastructure.
• 100-1,000 tenants, growth stage: Shared database with the option to migrate specific high-value tenants to dedicated schemas. Build the routing layer that allows per-tenant database configuration without changing application code.
• 1,000+ tenants or enterprise tier: Hybrid model where most tenants share a database but enterprise customers can opt into dedicated schemas or databases as a premium feature.

Decision 2: Monolith vs. Microservices

This is the most frequently debated and most frequently mishandled architectural decision in SaaS. The industry conversation around microservices has created a false impression that monoliths are legacy and microservices are modern. The reality is more nuanced.

The Case for Starting Monolithic

A monolith is a single deployable unit containing all of your application logic. “Monolith” does not mean “unstructured.” A well-architected monolith has clear module boundaries, defined interfaces between components, and the ability to extract services later without rewriting business logic.

Why monoliths win in early-stage SaaS:

• Deployment simplicity. One artifact to build, test, and deploy. One CI/CD pipeline. One set of logs to search. One process to monitor.
• Development speed. Calling a function is faster than designing an API contract, implementing serialization, handling network failures, and maintaining backward compatibility between services.
• Refactoring ease. When your product direction changes (and it will), renaming a function and updating its callers is a 30-minute task. Renaming an API endpoint and updating all consuming services is a multi-day coordination effort.
• Debugging simplicity. A stack trace in a monolith shows you the complete execution path. In microservices, you need distributed tracing infrastructure to reconstruct what happened across service boundaries.
• Team alignment. With fewer than 10-15 engineers, there is no organizational reason to split the codebase. Microservices solve a team coordination problem that does not exist at small scale.

When Microservices Become Necessary

Microservices are a response to two specific problems: team scaling and service scaling.

Team scaling: When you have 15+ engineers, a monolith becomes a coordination bottleneck. Merge conflicts increase, deployment queues grow, and teams step on each other’s code. At this point, splitting the monolith along team boundaries makes sense — not for technical reasons, but for organizational ones.

Service scaling: When specific parts of your system have fundamentally different scaling characteristics, independent services make sense. Your real-time notification system needs to handle 10,000 WebSocket connections while your billing service processes 50 events per minute. Scaling them together wastes resources. Scaling them independently requires separate services.

The Modular Monolith: The Best of Both Approaches

The pragmatic middle ground is a modular monolith. This is a single deployable application where internal modules have explicit boundaries, communicate through defined interfaces (not direct database access across modules), and can be extracted into services later with minimal rewriting.

Structure your monolith so that the billing module cannot directly query the user module’s database tables. Instead, it calls a function exposed by the user module’s internal API. When the day comes to extract billing into a service, that internal function call becomes an HTTP call, and the module becomes a service. The business logic does not change.

Cost impact: A well-structured modular monolith costs the same as a regular monolith to build initially (perhaps 5-10% more for interface discipline) but saves 60-70% of the cost of a premature microservices migration.

What Goes Wrong When You Choose Poorly

Premature microservices: A 5-person team spends 30% of their development time on infrastructure plumbing — service discovery, API gateway configuration, distributed tracing setup, inter-service retry logic, deployment orchestration. The product development velocity drops to half of what a monolith would deliver. Six months in, the team realizes they need to make a cross-cutting change that touches 4 services, and coordination overhead turns a 2-day task into a 2-week task.

Unstructured monolith without extraction path: The team builds a monolith without internal boundaries. Two years later, they need to extract the real-time component for independent scaling. Every module is entangled with every other module through direct database access, shared global state, and circular dependencies. The extraction project takes 6 months instead of 6 weeks.

Decision 3: API Design Paradigm

Your API is the contract between your frontend and backend, between your platform and your customers’ integrations, and between your current architecture and your future architecture. The paradigm you choose affects development speed, client performance, and long-term maintainability.

REST: The Default Choice for Good Reason

REST is well-understood, well-tooled, and appropriate for most SaaS products. Resource-oriented APIs with standard HTTP methods (GET, POST, PUT, DELETE) are intuitive for developers and supported by every HTTP client and framework.

Choose REST when:

• You are building a public API that external developers will consume
• Your resources are well-defined and map naturally to CRUD operations
• Your team is familiar with REST conventions and tooling
• You need excellent caching behavior (HTTP caching works naturally with REST)
• API simplicity and predictability are priorities

REST costs: €5,000-€12,000 for a well-designed REST API with documentation, versioning, and error handling conventions.

GraphQL: Power at the Cost of Complexity

GraphQL lets clients request exactly the data they need in a single query. No over-fetching, no under-fetching, no endpoint proliferation. It is genuinely superior for certain use cases.

Choose GraphQL when:

• Your frontend has complex, nested data requirements that would require multiple REST calls or custom endpoints
• You are building data-dense dashboards where different views need different subsets of the same data
• You have a mobile application where bandwidth efficiency matters
• Your internal teams need query flexibility without backend changes for every new view

Avoid GraphQL when:

• Your API is public-facing and consumed by third-party developers (REST is simpler for consumers)
• Your data model is flat and CRUD-oriented (GraphQL adds complexity without benefit)
• Your team has no GraphQL experience (the learning curve is real and affects the first 2-3 months of development)

GraphQL costs: €8,000-€18,000 for a production-quality GraphQL API. The additional cost comes from schema design, resolver optimization (N+1 query prevention), query complexity limiting, and client-side state management.

tRPC: Type-Safe Speed for Full-Stack TypeScript

tRPC provides end-to-end type safety between a TypeScript backend and TypeScript frontend with zero code generation and no schema definition. You change a backend function signature, and the frontend gets a type error immediately.

Choose tRPC when:

• Both frontend and backend are TypeScript (non-negotiable requirement)
• The API is internal — consumed only by your own frontend
• Development speed is the priority and you want maximum type safety with minimum overhead
• You do not need a public API (tRPC is not designed for third-party consumption)

tRPC costs: €3,000-€7,000. Lower than REST or GraphQL because there is less boilerplate, no schema definition, and no serialization configuration.

The Practical Decision Matrix

Factor	REST	GraphQL	tRPC
Public API needed	Best choice	Workable	Not suitable
Complex dashboards	Requires many endpoints	Excellent	Good (if TS stack)
Mobile clients	Good with careful design	Excellent (bandwidth)	Not suitable
Team experience	Universal	Requires training	Requires TypeScript
Caching	Native HTTP caching	Requires custom caching	Limited
Initial cost	€5-12K	€8-18K	€3-7K
Third-party tooling	Extensive	Growing	TypeScript only

The pragmatic approach for most SaaS: Use tRPC or REST for your internal API (frontend to backend). Add a REST API layer when you need to expose endpoints to customers or third-party integrations. This gives you development speed internally and interoperability externally.

Decision 4: Authentication Architecture

Authentication is not a feature. It is infrastructure that every other feature depends on. Getting it wrong means security vulnerabilities, user friction, and expensive rework when enterprise customers require SSO.

Session-Based vs. Token-Based (JWT)

Session-based authentication stores session state on the server (typically in a database or Redis). The client receives a session cookie that the server validates on each request.

Advantages: Session revocation is instant (delete the session record). No token size concerns. Works naturally with server-rendered applications. Simpler to reason about security.

Disadvantages: Requires server-side session storage that scales with user count. Sticky sessions or shared session stores needed in multi-server deployments. CSRF protection required for cookie-based sessions.

JWT (JSON Web Tokens) encode user identity and permissions into a signed token that the client sends with each request. The server validates the token signature without checking a database.

Advantages: Stateless — no server-side session storage. Works naturally with microservices (each service validates the token independently). Supports cross-domain authentication.

Disadvantages: Token revocation is difficult. JWTs are valid until they expire, so a compromised token cannot be instantly invalidated without additional infrastructure (token blacklists, short expiration + refresh tokens). Token size grows with embedded claims, increasing request payload size. Security footguns are numerous — algorithm confusion attacks, insecure token storage, excessive token lifetimes.

Recommendation: For most SaaS products, use session-based authentication with a managed service (Auth0, Clerk, or similar). If you are building a microservices architecture where multiple services need to validate authentication independently, use short-lived JWTs (5-15 minute expiration) with refresh tokens and a revocation mechanism.

SSO and Enterprise Authentication

Enterprise customers will require SAML or OIDC single sign-on. This is non-negotiable for selling to companies with more than a few hundred employees.

SAML is the legacy standard, still required by many enterprise identity providers (Okta, Azure AD, OneLogin). SAML implementation is notoriously complex — XML parsing, certificate management, assertion validation, and provider-specific quirks make it one of the highest-effort auth features.

OIDC (OpenID Connect) is the modern standard built on OAuth 2.0. It is simpler to implement, uses JSON instead of XML, and is supported by all modern identity providers. When possible, support OIDC and let enterprise customers configure it.

Cost of adding SSO: €5,000-€12,000 for the first two identity provider protocols. Budget an additional €2,000-€4,000 for each provider-specific quirk set (Microsoft Entra ID, Okta, and Google Workspace each have idiosyncrasies).

The pragmatic approach: Use a managed auth service that handles SAML and OIDC out of the box. The monthly fee for Auth0 or WorkOS is dramatically less than the engineering cost of building and maintaining enterprise SSO yourself.

Role-Based Access Control (RBAC)

Every SaaS needs an authorization model. Start with RBAC — predefined roles with associated permissions — and extend to more granular models only when the business requires it.

A well-designed RBAC system has three layers:

1. Roles defined at the organization/tenant level (Owner, Admin, Member, Viewer)
2. Permissions that map to specific actions (create:project, read:report, manage:billing)
3. Role-permission mappings that define what each role can do

Build the permission check as middleware that runs before every protected action. Use a centralized authorization function, not scattered if-statements throughout your codebase. When you need to audit who can do what, you should be able to answer that question by reading one file, not searching the entire codebase.

Cost of RBAC implementation: €3,000-€8,000 for a clean implementation with 3-5 roles. €10,000-€20,000 for advanced RBAC with custom roles, resource-level permissions, and an admin UI for role management.

Decision 5: Billing Integration Depth

Billing is where SaaS architecture meets business model. The complexity of your pricing model directly determines the complexity of your billing integration.

Simple Subscription Billing

Fixed-price plans (Basic, Pro, Enterprise) with monthly or annual billing. Stripe handles almost everything: checkout, subscription lifecycle, plan changes, invoicing, and basic dunning.

Implementation scope:

• Stripe Checkout or embedded pricing page
• Webhook handlers for subscription events (created, updated, canceled, payment failed)
• Plan gating logic (check the customer’s current plan before allowing access to features)
• Billing portal for customers to manage payment methods and view invoices

Cost: €3,000-€5,000. Well-documented, straightforward, and Stripe’s libraries handle the heavy lifting.

Usage-Based and Metered Billing

Pricing based on API calls, storage used, messages sent, seats active, or any measurable unit. This is where billing complexity escalates significantly.

Implementation scope:

• Event tracking — every billable action must be captured, timestamped, and attributed to a tenant
• Aggregation pipeline — events must be aggregated into billing periods (hourly, daily, monthly)
• Usage reporting — customers need real-time visibility into their current usage and projected costs
• Billing cycle management — proration for mid-cycle changes, overage calculations, usage caps with soft and hard limits
• Stripe metered billing integration or a custom billing engine
• Reconciliation — comparing your tracked usage against Stripe’s records to catch discrepancies

Cost: €10,000-€25,000. The difficulty is not in any single component but in the reliability requirement. Billing errors — charging too much or too little — destroy customer trust faster than almost any other bug.

Dunning and Payment Recovery

When a payment fails, what happens? Without proper dunning, you lose customers to expired credit cards — a problem that is entirely preventable.

A proper dunning system includes:

• Automatic retry schedule (retry at 1 day, 3 days, 7 days after failure)
• Customer notifications at each retry with a link to update payment information
• Grace period management — do not immediately revoke access on first payment failure
• Escalation — notify your team when a high-value customer’s payment has failed multiple times
• Voluntary churn vs. involuntary churn tracking — these require different responses

Cost: €2,000-€5,000 for a basic dunning flow. Stripe’s built-in Smart Retries handle some of this, but customer-facing notifications and grace period logic require custom implementation.

What Goes Wrong When You Choose Poorly

Under-investing in billing: You launch with basic Stripe Checkout and hard-coded plan logic. Six months later, you need to offer annual discounts, usage-based add-ons, and custom enterprise pricing. The billing code is scattered across the codebase, plan changes are error-prone, and every pricing experiment requires a code deployment. Refactoring the billing system takes 8-12 weeks and blocks other development.

Over-engineering billing: You build a flexible billing engine before you have validated your pricing model. Six months later, your pricing model has changed three times, and most of the billing engine’s flexibility was never used. You spent €20,000 on billing infrastructure that a €5,000 Stripe integration would have served equally well.

Decision 6: Deployment Topology

How you deploy your application affects reliability, performance, cost, and your team’s ability to ship updates quickly.

Single-Region Deployment

Your entire application runs in one geographic region (e.g., eu-west-1 for European users, us-east-1 for North American users).

Advantages: Simplest to operate. Lowest cost. No cross-region replication complexity. Sufficient for the vast majority of SaaS products.

Disadvantages: Users far from your region experience higher latency. A regional outage takes down your entire application. Data residency compliance may require serving specific markets from specific regions.

When this is sufficient: When your users are primarily in one geographic region, your application is not latency-sensitive beyond normal web expectations (sub-500ms page loads), and you do not have data residency requirements.

Multi-Region Deployment

Your application runs in multiple geographic regions with data replication between them.

Advantages: Lower latency for global users. Regional failover capability. Data residency compliance by routing users to region-appropriate instances.

Disadvantages: Dramatically more complex. Database replication introduces consistency challenges (eventual consistency, conflict resolution). Deployment coordination across regions is non-trivial. Cost is 2-4x that of single-region. Debugging requires understanding which region served which request.

When this is necessary: When you have contractual SLA requirements that demand geographic redundancy, when you serve users across multiple continents and latency directly impacts user experience (real-time collaboration, trading platforms), or when data residency regulations require data to stay within specific geographic boundaries.

Cost impact: Single-region deployment costs €2,000-€5,000 to set up. Multi-region adds €15,000-€30,000 in initial engineering and 2-4x ongoing infrastructure costs.

Container Orchestration

Docker without orchestration: Containerize your application with Docker and deploy to a single server or small cluster. Sufficient for most startups through Tier 2.

Docker with simple orchestration (Docker Compose, Docker Swarm): Run multiple containers on a small cluster with basic service discovery and load balancing. Appropriate when you need 2-5 services but do not need the complexity of Kubernetes.

Kubernetes: Full container orchestration with auto-scaling, self-healing, service mesh, rolling deployments, and resource management. Appropriate when you have 10+ services, need sophisticated auto-scaling, or have a team with Kubernetes expertise.

The honest recommendation: Do not use Kubernetes until you have a dedicated platform/DevOps engineer. Kubernetes solves real problems, but the operational overhead is substantial. A Docker Compose setup on a well-provisioned server can handle more load than most founders expect, and it costs a fraction of a Kubernetes cluster to operate.

CDN and Edge Strategy

Use a CDN (Cloudflare, AWS CloudFront, Bunny CDN) for static assets from day one. The cost is minimal (often free tier is sufficient), the performance improvement is significant, and it offloads bandwidth from your application servers.

For API responses, CDN caching is appropriate for public, read-heavy endpoints (product catalogs, public content) but requires careful cache invalidation logic for authenticated or frequently changing data.

Decision 7: Observability Stack

You cannot manage what you cannot observe. Observability — the combination of logging, monitoring, alerting, and tracing — is what separates a professional SaaS operation from a “we will fix it when users complain” operation.

The Three Pillars of Observability

Logging: Structured, searchable records of what happened in your application. Not console.log statements scattered through the codebase — structured JSON logs with consistent fields (timestamp, request ID, tenant ID, user ID, action, result).

Metrics: Numerical measurements over time. Request latency, error rates, database query times, queue depths, active WebSocket connections, API response times by endpoint. Metrics tell you whether your system is healthy and where performance is degrading.

Traces: End-to-end request tracking across your application (and across services, if you have them). A trace shows you that a slow dashboard page load was caused by a database query in the reporting module that was scanning the full table instead of using an index.

Minimum Viable Observability

Every SaaS product should launch with these essentials:

• Error tracking: Sentry, Bugsnag, or equivalent. Automatic error capture with context (which user, which tenant, what they were doing). Cost: free tier is usually sufficient for the first year.
• Uptime monitoring: Betterstack, UptimeRobot, or similar. External checks that verify your application is responding. Cost: free-€20/month.
• Application performance monitoring (APM): Datadog, New Relic, or Grafana Cloud. Request timing, database query analysis, and bottleneck identification. Cost: free tier or €50-€200/month depending on volume.
• Log aggregation: Centralized, searchable logs. Betterstack (formerly Logtail), Datadog Logs, or a self-hosted Loki/Grafana stack. Cost: free tier or €20-€100/month.
• Alerting: PagerDuty, Opsgenie, or alerting built into your monitoring tool. Alert on error rate spikes, latency increases, and resource exhaustion. The key is alert discipline — alert on actionable conditions, not on noise.

Cost of minimum viable observability: €5,000-€10,000 for setup and integration, plus €100-€500/month for tooling.

Production-Grade Observability

For growth-stage and enterprise SaaS, add:

• Distributed tracing: OpenTelemetry integration that traces requests across your application stack. Essential for diagnosing performance issues in complex systems.
• Custom business metrics: Track business-relevant metrics (signups, feature adoption, conversion events) alongside technical metrics. This is where observability meets product analytics.
• SLA monitoring: If you promise 99.9% uptime in customer contracts, you need to measure and report on it accurately. Budget €3,000-€5,000 for SLA tracking infrastructure.
• Runbooks: Documented procedures for responding to alerts. When the database connection pool alert fires at 3 AM, the on-call engineer should know exactly what to check and what actions to take. This is documentation work, not engineering, but it is critical.

What Goes Wrong When You Choose Poorly

No observability: A customer reports that the dashboard is slow. You have no metrics to confirm or deny it, no traces to identify the cause, and no logs to reconstruct what happened. You spend three days guessing instead of three hours diagnosing. Multiply this by every performance issue, every bug report, and every outage.

Excessive observability: You instrument everything, generate terabytes of logs, and set up 200 alerts. Your monitoring bill is €2,000/month, your alerts fire so often that the team ignores them, and no one can find the signal in the noise. Over-monitoring is almost as bad as under-monitoring because it creates a false sense of security.

The right approach: Start with error tracking and uptime monitoring before launch. Add APM and log aggregation in the first month of production. Add distributed tracing and custom metrics when you identify specific performance questions that basic monitoring cannot answer.

Putting It All Together: Architecture at Each Growth Stage

Pre-Launch to 100 Users

• Shared database multi-tenancy with row-level security
• Modular monolith with clear internal boundaries
• REST or tRPC for internal API
• Managed authentication (Auth0, Clerk)
• Basic Stripe subscription billing
• Single-region Docker deployment
• Error tracking + uptime monitoring

Total architecture cost: €15,000-€30,000 (included in MVP development budget).

100 to 1,000 Users

• Add tenant-specific configuration and onboarding
• Extract performance-critical modules if needed (search, real-time)
• Add GraphQL or REST API for customer integrations
• Implement SSO for enterprise prospects
• Extend billing for usage tracking and add-ons
• Add staging environment and CI/CD hardening
• Full observability stack (APM, logging, alerting)

Architecture evolution cost: €20,000-€50,000 over 6-12 months.

1,000 to 10,000 Users

• Hybrid multi-tenancy (shared + dedicated for enterprise)
• Begin extracting bounded contexts into services as team grows
• Public API with documentation, rate limiting, and API keys
• SCIM provisioning and directory sync
• Advanced billing engine with custom pricing
• Multi-region consideration, CDN optimization
• SLA monitoring, runbooks, incident response process

Architecture evolution cost: €50,000-€120,000 over 12-18 months.

The Architect’s Responsibility

These seven decisions are not isolated technical choices. They interact with each other in ways that create compound effects — positive or negative.

Choosing database-per-tenant multi-tenancy makes microservices more complex because each service needs tenant routing. Choosing GraphQL makes observability harder because every request hits the same endpoint. Choosing JWT authentication makes session revocation harder, which affects your security posture, which affects your compliance readiness.

The architect’s job is not to make each decision in isolation but to make a coherent set of decisions that work together and create a platform that can evolve as the business grows. Every decision should be made with an explicit understanding of its interaction with the other six.

The best architecture is one you can explain to your future self in six months and defend to your largest customer’s security team. If a decision does not meet both criteria, reconsider it.

Architecture is not a one-time activity. It is a continuous practice of evaluating whether your current decisions still serve your current needs, and having the discipline to evolve when they do not.