Backend, APIs, and System Design
API design, database choice, distributed patterns, and the engineering decisions that compound for years.
Serverless vs Containers vs Bare Metal: A Cost and Flexibility Map
Compute models for web applications describe how application code is executed and billed. Serverless functions (AWS Lambda, Vercel Functions, Cloudflare Workers) execute code on demand and bill per invocation and execution time, with nothing running around the clock to manage. Containers (Docker on ECS, Kubernetes, Railway, Render) package application code with its runtime and run as processes that stay on continuously or scale automatically. Bare metal or VPS hosting runs application code on dedicated or virtual machines where the team manages the operating system and runtime environment.
Backend, APIs, and System DesignServer Actions, Edge Functions, and the Modern Backend Surface
The modern backend surface for web applications encompasses multiple execution environments: traditional API servers (Node.js, Python, Go running on centralized servers), edge functions (short lived JavaScript functions running close to the user on distributed edge networks), and server actions (server functions specific to Next.js, called directly from client components without an explicit API route). Each environment has different latency characteristics, available APIs, and appropriate use cases. The choice between them affects performance, development model, and infrastructure cost.
Backend, APIs, and System DesignSchema Evolution: Adding Columns Without Downtime
Schema evolution refers to the process of modifying a database schema (adding columns, changing types, dropping tables, creating indexes) while the application is running and serving production traffic. Migrating schema without downtime requires careful sequencing of DDL statements, application code changes, and data backfills to avoid table locks that block reads and writes, and to maintain compatibility between the old and new application code during the deployment window.
Backend, APIs, and System DesignSaga Patterns: Distributed Transactions Without Distributed Pain
The saga pattern manages distributed transactions by breaking a multi step operation into a sequence of local transactions, each with a compensating transaction that reverses its effects on failure. When a step fails, the saga executes compensating transactions for all previously completed steps, returning the system to a consistent state without requiring distributed locks or two phase commit. Sagas are the standard approach to long running transactions in microservices and multi service architectures.
Backend, APIs, and System DesignREST vs GraphQL vs gRPC: A Decision Matrix for Founders
REST, GraphQL, and gRPC are API design paradigms that determine how clients and servers communicate. REST uses HTTP methods and resource URLs with JSON responses, following the constraints of the web architecture. GraphQL is a query language where clients specify exactly what data they need in a single request, reducing both over fetching and under fetching. gRPC uses Protocol Buffers over HTTP/2 for strongly typed, high performance communication between services, primarily used for internal service to service communication. The choice between them is primarily determined by who the API clients are and what the communication requirements are.
Backend, APIs, and System DesignResilience Patterns: Circuit Breakers, Retries, Bulkheads
Resilience patterns are design techniques that allow distributed systems to continue functioning when individual components fail or degrade. Circuit breakers prevent cascading failures by stopping requests to a failing dependency before the failure spreads. Retries with exponential backoff recover from transient failures without creating retry storms. Bulkheads isolate failures to a subset of resources so that one failing dependency cannot consume all available capacity and degrade unrelated functionality. Together they form the baseline resilience architecture for services that depend on external APIs, databases, and other network connected components.
Backend, APIs, and System DesignRate Limiting Algorithms Compared: Token Bucket, Leaky Bucket, Fixed Window
Rate limiting is the practice of restricting how many requests a client can make to an API within a time window. The algorithm used determines how requests are counted, when limits are enforced, and how burst traffic is handled. Common algorithms include fixed window (simple count per time period), sliding window (count across a rolling time period), token bucket (tokens regenerate at a fixed rate, bursts are allowed up to bucket capacity), and leaky bucket (requests are queued and processed at a fixed rate, smoothing burst traffic).
Backend, APIs, and System DesignQuery Optimization in PostgreSQL: Real Examples From Real Projects
PostgreSQL query optimization is the process of analyzing slow queries using EXPLAIN ANALYZE output, identifying the root cause (missing index, sequential scan, poor join order, N+1 pattern), and applying targeted fixes that reduce execution time. Optimization in PostgreSQL is driven by evidence: the planner's cost estimates and actual row counts in EXPLAIN output reveal which part of the query is expensive and why.
Backend, APIs, and System DesignPostgreSQL vs Supabase vs Neon vs Planetscale
Self managed PostgreSQL on a cloud provider, Supabase, Neon, and PlanetScale represent a spectrum from full operational control to maximum managed convenience for database infrastructure. Each choice involves tradeoffs between engineering time spent on database operations, feature access, pricing structure, and vendor dependency. For most early stage SaaS products, the managed platforms provide enough benefit to justify their cost and feature restrictions. For high scale or compliance sensitive applications, self managed infrastructure provides control that managed platforms cannot.
Backend, APIs, and System DesignPostgreSQL vs MySQL vs MongoDB for a New SaaS in 2026
PostgreSQL, MySQL, and MongoDB are the three most commonly evaluated database choices for new SaaS applications. PostgreSQL is a relational database with strong ACID compliance, extensive feature set (JSON columns, full-text search, geometric types, extensions), and broad managed hosting support. MySQL is a relational database with wide compatibility and specific advantages in read-heavy workloads. MongoDB is a document database that stores data as JSON documents without enforcing a schema. Each has appropriate use cases and inappropriate use cases for SaaS applications.
Backend, APIs, and System DesignPagination Patterns: Cursor vs Offset and Why It Matters
Pagination is the mechanism for breaking large dataset results into smaller pages. Offset pagination (LIMIT/OFFSET in SQL) skips a fixed number of rows to retrieve a specific page. Cursor pagination uses a position marker from the previous page to retrieve the next set of results. Offset pagination is simpler but produces inconsistent results on live data and degrades in performance on large offsets. Cursor pagination is more complex but produces consistent results and performs well regardless of dataset size.
Backend, APIs, and System DesignOAuth 2.0 Without Tears: A Founder Engineer's Guide
OAuth 2.0 is an authorization framework that allows applications to access resources on behalf of a user without handling or storing the user's credentials. The user authorizes the application through an authorization server (Google, GitHub, Okta) and the application receives an access token it can use to call APIs. OAuth 2.0 defines several flows (authorization code, implicit, client credentials, device code) for different use cases. Implementing the wrong flow or mishandling tokens introduces security vulnerabilities.
Backend, APIs, and System DesignMessage Queues Compared: SQS, Kafka, RabbitMQ, Redis Streams
Message queues decouple the production of work from its consumption: a producer writes a message to the queue, and a consumer reads and processes it independently. The choice between SQS, Kafka, RabbitMQ, and Redis Streams determines the delivery semantics, retention behavior, throughput ceiling, and operational complexity of your async processing infrastructure. Each tool has a different performance profile and a different use case where it is the natural fit.
Backend, APIs, and System DesignLambda Cold Starts: Why They Still Matter in 2026
A Lambda cold start is the latency added to a function invocation when AWS must provision a new execution environment because no warm environment is available. Cold starts add anywhere from 100 milliseconds for simple Node.js functions to several seconds for large Java or .NET functions with complex initialization. Despite significant improvements in the AWS Lambda runtime, cold starts remain a meaningful performance consideration for production workloads where latency matters.
Backend, APIs, and System DesignKafka in 2026: When You Need It and When You Do Not
Kafka is a distributed event streaming platform built for high throughput, fault tolerant message delivery at massive scale. It processes millions of events per second, stores them durably on disk, and replays them on demand. Most companies do not need this. The ones that do are processing analytics in real time, coordinating between dozens of services, or running systems where losing a single event means losing money.
Backend, APIs, and System DesignJSON Columns in Postgres: When They Make Sense
JSON columns in Postgres (using the jsonb type) store semi structured data alongside relational data in the same table. They are appropriate when data has variable or unpredictable structure, when the fields inside the JSON do not need to be individually indexed or queried in SQL, and when the alternative would be a wide table with many nullable columns or a complex EAV (entity, attribute, value) schema. They are not a substitute for proper relational design.
Backend, APIs, and System DesignIdempotency Keys: A Pattern Every Senior Engineer Should Master
An idempotency key is an identifier the client generates and attaches to a write request, letting the server detect and deduplicate repeated calls to the same operation. The pattern converts an operation with side effects from one that is unsafe to retry into one that is safe to retry, which is the difference between a payment system that occasionally charges twice and one that never does.
Backend, APIs, and System DesignGeospatial Data Done Right: PostGIS and Beyond
PostGIS is the Postgres extension that adds geometric and geographic types, spatial indexes, and spatial functions. The extension turns Postgres into a real geospatial database. The setup is one command. The performance is excellent on the queries most products need. Distance, contains, nearest, and routing all work. Most products that need location queries should use PostGIS rather than a specialized store.
Backend, APIs, and System DesignFull Text Search in PostgreSQL: Practical Patterns
Postgres full text search uses tsvector and tsquery to index and search text. The setup is mechanical. The performance is solid into the millions of rows for most queries. The features are sufficient for most SaaS search needs. Most teams reach for Elasticsearch or Algolia preemptively when Postgres full text would have served them for years. The patterns are small and worth learning.
Backend, APIs, and System DesignEventual Consistency in Plain Language for Founders
Eventual consistency means the state of the system reaches a consistent value some time after the change. The window where state is inconsistent is small in well designed systems and meaningful in poorly designed ones. Almost every modern web application has eventual consistency somewhere. The teams that handle it well design for the consistency window. The teams that pretend it does not exist ship bugs that confuse customers.
Backend, APIs, and System DesignEvent Sourcing: A Pattern Worth Understanding Even If You Do Not Use It
Event sourcing is the pattern of storing every change as an event in an append only log. The current state of any entity is derived by replaying the events. The pattern provides perfect audit, time travel, and the ability to derive new views from historical data. The full implementation is rare in SaaS because of the operational complexity. The concepts shape good thinking about state even in systems that do not adopt the pattern fully.
Backend, APIs, and System DesignDomain Driven Design for SaaS: A Practical Subset
Domain Driven Design is a set of patterns for modeling complex business domains in code. The full method has heavy ceremony. The practical subset that helps SaaS teams is small. Bounded contexts give you clear module boundaries. Ubiquitous language keeps engineering and product talking about the same things. Aggregates protect consistency across related entities. Three patterns. Used well, they prevent the architectural mess that grows from absent design.
Backend, APIs, and System DesignDesigning for Failure: A Backend Engineer's Mental Model
Designing for failure means assuming that every dependency can fail and building the application to degrade gracefully rather than cascade. Timeouts. Retries with backoff. Circuit breakers. Bulkheads. Graceful degradation. Each is a small pattern that prevents a small failure from becoming a customer facing incident. The mental model is that failures are normal and the system should handle them as such.
Backend, APIs, and System DesignDesigning for Audit From the Start
A system designed for audit captures every sensitive action with enough context that an auditor can reconstruct what happened. The discipline is in the design, not in the bolt on logging after the fact. Append only audit storage, tenant scoped queries, retention that fits the regime, and an auditor friendly query interface. The investment at week one is small. The retrofit at year three when an auditor demands evidence is a quarter of work.