Sanjoy Kumar Malik

In software engineering, architectural styles define the fundamental organization and interaction patterns of a system’s components. They influence not only the internal qualities of the software — such as scalability, maintainability, and performance — but also how quickly and reliably teams can deliver functional increments to end users. An architectural choice is effectively a strategic decision with long-term delivery and operational consequences. This article analyzes common architectural styles and how they shape delivery outcomes, drawing on industry resources and research.

Defining Architectural Styles​

An architectural style establishes high-level structure for software systems: how modules are organized, how they communicate, and how responsibilities are distributed. Architectural styles range from traditional layered systems to highly distributed microservices and event-driven solutions. Each style exists independent of specific technologies but affects development and delivery practices directly.

"An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. Constraints guide the "shape" of an architecture by restricting the universe of choices. When an architecture conforms to the constraints of a particular style, certain desirable properties emerge." ~ Azure Architecture Center

In the early stages of a product’s life, the world is small. Your users are likely concentrated in one region, and your stack lives in a single data center. But as a service scales, a fundamental physical reality begins to intrude upon the user experience: the speed of light.

When a user in Singapore attempts to access a service hosted in North Virginia, the packets must travel roughly 15,000 Kilometers. Even at the theoretical limit of light in a vacuum, the round-trip time (RTT) is approximately 100 milliseconds. In the messy reality of fiber optics and router hops, this often balloons to 200ms or 300ms. For a modern interactive application, this isn't just a delay; it is a structural barrier to engagement and retention.

Latency Becomes a First-Order Constraint​

Every large system eventually encounters a moment when latency stops being an abstract metric and becomes a user-visible problem. Pages feel slow. Interactions feel unresponsive. Customers in distant geographies complain about “sluggishness.” At this point, latency is no longer a tuning problem. It is a structural constraint.

In early-stage systems, latency is often treated as an operational concern. Add caching. Optimize queries. Scale vertically. These tactics work until they don’t. Once users are distributed across continents, physical distance introduces an irreducible delay. No amount of local optimization can overcome the speed of light.

This is where many teams make a critical mistake: they treat “adding regions” as a deployment decision rather than an architectural one. They assume geo-distribution is primarily about spinning up infrastructure closer to users. In reality, geo-distribution reshapes how data is owned, how consistency is defined, how failures manifest, and how teams operate.

Distance introduces hidden costs: coordination latency, replication lag, partial failures, and operational complexity. These costs compound as systems grow. Geo-distribution is therefore not a best practice to be adopted early. It is an inflection point and a response to scale that forces explicit architectural trade-offs.

Most systems begin their lives with an implicit assumption: data is consistent because the database makes it so. Early architectures rely on defaults—single instances, synchronous writes, transactional guarantees—without consciously choosing a consistency model. At small scale, this works. At larger scale, it quietly fails.

As systems grow, data volume and traffic increase linearly or even exponentially. Teams add capacity, scale out infrastructure, and introduce replicas. Throughput improves. Storage grows cheaply. And yet, latency spikes, anomalies appear, and correctness becomes harder to reason about. The bottleneck is no longer compute or disk. It is coordination.

Consistency stops scaling at the same rate as data and traffic because consistency is fundamentally about agreement. Agreement requires coordination, and coordination is constrained by latency, failure, and contention. While storage can be partitioned and reads can be replicated, agreement cannot be parallelized without cost.

This is the moment when consistency transitions from being an invisible database feature to an explicit architectural concern. Choices that were once implicit now define system behavior under load and failure. Consistency becomes a growth constraint, not because databases are weak, but because correctness has a price.

At this point, treating consistency as an implementation detail becomes dangerous. It is no longer something that can be tuned away. It is an architectural commitment that shapes system limits, failure modes, and team behavior.

What “Scalable Data Infrastructure” Really Means​

Scalable data infrastructure is often misunderstood as the ability to store more data or serve more queries. While necessary, those capabilities are insufficient to describe real scalability.

Types of Data Duplication​

Data duplication manifests in various forms, each tailored to specific needs in system design. Understanding these types helps architects decide when and how to employ them.

First, read-optimized copies. These are denormalized replicas designed for query efficiency. In relational databases, this might mean materializing views or using NoSQL stores like Cassandra for fast reads. For instance, in a social media app, user profiles are duplicated across edge caches to minimize database hits, ensuring sub-millisecond response times.

Next, cache-like projections. These are transient duplicates, such as Redis caches holding subsets of data from a primary store. They are not meant to be permanent but act as accelerators. In event-driven systems using Kafka, projections might create specialized views, like a user's feed aggregated from multiple sources, duplicated for quick access.

Finally, derived and aggregated data. This involves computing new data from originals, like summaries or roll-ups. In analytics platforms, tools like Apache Spark duplicate raw logs into aggregated tables for BI dashboards. Think of financial systems where transaction data is duplicated into ledgers for real-time reporting, derived from core accounting records.

Each type serves a purpose, but they all introduce redundancy. The art lies in choosing the right form without overcomplicating the ecosystem.

Benefits When Done Intentionally​

When architects embrace data duplication thoughtfully, it yields significant advantages, transforming potential liabilities into strengths.