DEV Community

Cover image for The 5 System Design Tradeoffs Every Backend Engineer Must Navigate
DEVANSHU PATIL
DEVANSHU PATIL

Posted on AI-assisted

The 5 System Design Tradeoffs Every Backend Engineer Must Navigate

#systemdesign #architecture #backend #programming

The 5 System Design Tradeoffs Every Backend Engineer Must Navigate

In software engineering, there are no solutions—only tradeoffs.

Every architectural decision that boosts one metric inevitably extracts a cost from another:

  • Adding a cache reduces read latency, but increases system complexity and stale data risks.
  • Adding database indexes speeds up queries, but degrades write throughput and bloats disk storage.
  • Breaking up a monolith gives deployment autonomy, but introduces network latency and distributed debugging headaches.

Senior engineers are not distinguished by knowing every framework; they are distinguished by their ability to evaluate and navigate fundamental architectural tradeoffs.

Here are the 5 system design tradeoffs you will encounter in every technical design document and system design interview.

1. Consistency vs. Availability (The CAP Theorem)

In any distributed data store, network partitions ($P$) are a physical inevitability—fiber cables get cut, routers reboot, and cloud availability zones lose connectivity.

When a partition occurs between Data Center East and Data Center West, you must make a choice:

                  +----------------------------------+
                  |  Network Partition Occurs (P)    |
                  +----------------------------------+
                                   |
         +-------------------------+-------------------------+
         |                                                   |
         v                                                   v
[CP: Choose Consistency]                            [AP: Choose Availability]
- Refuse writes on disconnected nodes.              - Accept writes on all nodes.
- Maintain 100% data correctness.                  - System stays 100% online.
- Client receives HTTP 500 error.                   - Data temporarily diverges!
(e.g., PostgreSQL primary, Etcd, ZooKeeper)         (e.g., Cassandra, DynamoDB, DNS)
Enter fullscreen mode Exit fullscreen mode
  • Choose CP for financial ledgers, ticketing reservations, and inventory stock counts.
  • Choose AP for social media feeds, analytics counters, and messaging channels.

2. Latency vs. Throughput

  • Latency: The time required to process a single request (measured in milliseconds).
  • Throughput: The total volume of work completed per unit time (measured in Requests Per Second - RPS).

Optimizing for peak throughput often increases individual request latency!
For example: Batching. Buffering requests and inserting in batches of 500 every 100ms increases individual request latency to 100ms, but total system throughput surges from 200 RPS to 10,000 RPS!

3. Normalization vs. Denormalization 

Normalized (3NF):
[Users Table] <--- (Foreign Key Join) ---> [Orders Table]
- Zero data redundancy. Single source of truth.
- Requires expensive JOIN queries across large tables.

Denormalized:
[Orders Table: { order_id, customer_name, customer_email, total }]
- Blazing-fast single-table reads (No joins!).
- Redundancy: If user changes email, you must update millions of records or accept stale historical data.
Enter fullscreen mode Exit fullscreen mode

4. Push vs. Pull Communication

  • Pull (Polling): Consumer queries the server periodically (GET /updates?since=12:00). Simple, stateless, but introduces latency.
  • Push (Streaming / Webhooks / WebSockets): Server pushes events immediately as they occur. Real-time, but requires maintaining stateful persistent connections and backpressure controls.

5. Strong vs. Eventual Consistency

  • Strong Consistency: Every read receives the most recent write immediately (Linearizability).
  • Eventual Consistency: All replicas will eventually converge to the same value, but reads may temporarily return older data for a few hundred milliseconds.

In modern cloud architectures, achieving global Strong Consistency across continents requires coordinating with the speed of light in fiber optics (~100ms roundtrip delay). Eventual consistency allows local edge servers to respond in 5ms, paying the synchronization tax in the background.

How to Make Architectural Decisions

When presenting technical designs to your team or stakeholders, never say: "This is the best tool."

Say: "We chose Technology X over Technology Y because in our current phase, **Latency and Developer Simplicity* matter more to our business than Global Multi-Region Replication. If write volume increases 10x, we will revisit this decision by migrating to Pattern Z."*

Engineering maturity is knowing what you are trading away—and choosing the compromise intentionally.

Top comments (0)