Unveiling the Architecture: Frontend, Backend, and Database in Practice - DEV Community

The basic three-tier architecture model, splitting applications into frontend, backend, and database layers, is often taught as a static, isolated set of definitions. Frontend is what the user sees, backend is the business logic, database is where data lives. This simplified view works for toy projects, but it falls apart when building production systems that need to scale, handle partial outages, or maintain data consistency across distributed components.

The original DEV Community post and accompanying video series by Marcelo Cabral cover this foundational model, including a companion video explaining how these layers interact for beginners. The post is paired with a blog entry on Marcelo Cabral's site and a video walkthrough. You can watch the accompanying video here, which breaks down the basics for new developers. This article expands on that foundation to cover the distributed systems tradeoffs that become critical as applications grow beyond single-server deployments.

Let's start with the problem that simplified architecture models ignore. When developers treat each layer as a black box, they make design choices that create single points of failure, unnecessary latency, or data inconsistency. A common example: a frontend that makes 12 sequential API calls to render a single dashboard, each waiting for the previous to finish. This adds hundreds of milliseconds of latency, and if any single backend call fails, the entire dashboard breaks. Another example: a backend that writes all data to a single PostgreSQL instance with no replication. If that instance goes down for maintenance or due to a hardware failure, the entire application is unavailable, and data written during the outage is lost if the storage fails.

The solution is not to abandon the three-tier model, but to understand each layer's role in a distributed context, along with the tradeoffs of every design choice.

Frontend: More Than Just UI

The frontend layer is the client-facing component, but its design has outsized impacts on backend load and user experience. For web applications, frontend assets (HTML, CSS, JavaScript) are static, so they should be served via CDNs like Cloudflare or AWS CloudFront to reduce latency and offload traffic from the backend. Client-side caching of API responses reduces redundant requests, but requires cache invalidation logic to avoid showing stale data.

Rendering patterns are a key tradeoff here. Server-side rendering (SSR) generates full HTML on the backend, which improves SEO and initial load time for users with slow connections, but increases backend load. Client-side rendering (CSR) shifts rendering to the browser, reducing backend load but hurting SEO and initial load performance. Many modern frameworks like Next.js support hybrid rendering, allowing developers to choose SSR for marketing pages and CSR for interactive dashboards.

Frontend API consumption patterns also matter. Batching multiple requests into a single call (using GraphQL or custom batch endpoints) reduces network overhead. Implementing retries with exponential backoff for failed requests improves resilience, but requires idempotency keys on the backend to avoid duplicate writes. Polling for updates every few seconds creates unnecessary load, while WebSockets or server-sent events (SSE) push updates to the client only when data changes.

Backend: Logic, APIs, and Scalability

The backend layer handles business logic, authentication, data validation, and communication between the frontend and database. A critical early choice is the API pattern, which dictates how frontend and backend communicate.

REST is the most common pattern, using HTTP methods (GET, POST, PUT, DELETE) to interact with resource endpoints. It is stateless, cacheable, and easy to implement, but often leads to over-fetching (requesting more data than needed) or under-fetching (needing multiple requests to get all required data). GraphQL solves this by letting clients specify exactly the data they need in a single query, but shifts complexity to the backend, which must resolve nested queries efficiently. For internal communication between backend services, gRPC uses binary Protocol Buffers for high-performance, low-latency calls, but requires more setup than REST.

Scalability for the backend relies on stateless design. Storing session data in a shared cache like Redis instead of local server memory means any backend instance can handle any request, allowing horizontal scaling by adding more servers behind a load balancer. Monolithic backends are simple to build initially, but a bug in one component can take down the entire system. Microservices split the backend into independent services, improving fault isolation but adding complexity for service discovery, distributed tracing, and cross-service transactions.

Database: Persistence and Consistency

The database layer is the source of truth for application data, but tradeoffs between consistency, scalability, and availability define its design. SQL databases like PostgreSQL offer ACID compliance (atomicity, consistency, isolation, durability), making them ideal for transactional data like orders or financial records. They support strong consistency, meaning a write is immediately visible to all subsequent reads, but scale vertically (adding more CPU/RAM to a single instance) or via read replicas, which only improve read throughput.

NoSQL databases like MongoDB or Cassandra offer flexible schemas and horizontal scaling via sharding, but often sacrifice strong consistency for eventual consistency. Eventual consistency means writes may not be immediately visible to all readers, but the system remains available during network partitions. The CAP theorem formalizes this tradeoff: distributed systems can only guarantee two of three properties: consistency, availability, and partition tolerance. For example, a CP system like etcd prioritizes consistency and partition tolerance, sacrificing availability during network splits. An AP system like Cassandra prioritizes availability and partition tolerance, accepting temporary inconsistent reads.

Scalability for databases requires careful planning. Read replicas split read traffic from write traffic, but all writes still go to a single primary instance, which becomes a bottleneck for write-heavy workloads. Sharding splits data across multiple instances based on a shard key (like user ID), improving write throughput but complicating cross-shard queries and transactions.

Component Communication and Tradeoffs

The core interaction between layers is the request-response cycle: frontend sends a request to the backend via an API, the backend processes the request, queries the database if needed, and returns a response. This can be synchronous, where the frontend waits for the backend to respond, or asynchronous, where the backend queues a job and returns a confirmation immediately, processing the job later.

Synchronous communication is simpler to implement and debug, but creates tight coupling. If the backend is slow or unavailable, the frontend blocks, leading to a poor user experience. Asynchronous communication via message queues like Apache Kafka or AWS SQS decouples components, so a backend outage doesn't prevent the frontend from accepting requests. However, it adds complexity: events must be idempotent (processing the same event twice doesn't cause duplicate side effects), event ordering must be preserved if needed, and the frontend must poll or use callbacks to check job status.

Real-World Examples

A startup building an MVP for an e-commerce app might start with a monolithic backend using Express.js, a PostgreSQL database, and a React frontend. This is fast to build, but as traffic grows, they add read replicas to PostgreSQL to handle more product page views, then split the backend into microservices for orders, users, and products. They switch from REST to gRPC for internal service communication to reduce latency, and add a Redis cache for frequently accessed product data.

A social media app uses eventual consistency for user feeds: when a user posts a photo, it may take a few seconds to appear in their friends' feeds, which is acceptable. For direct messages, they use strong consistency to ensure messages are delivered immediately and reliably. Their frontend uses SSR for public profiles to improve SEO, and CSR for the private feed to reduce backend load.

Conclusion

The basic three-tier architecture model is a necessary starting point, but production systems require understanding the tradeoffs of every layer. Frontend choices affect latency and backend load. Backend API and scalability choices determine fault tolerance and growth capacity. Database consistency and scalability choices define data reliability and write throughput. The companion video and blog post cover the basics of how these layers fit together, while the patterns here help extend that model to distributed systems that survive real-world failures and scale to millions of users.