Microservices vs Modular Monolith in 2026: Why Startups Are Consolidating Architecture

# Microservices vs Modular Monolith in 2026: Why Startups Are Consolidating Architecture

Direct Answer Summary: In 2026, engineering teams are consolidating fragmented microservices back into disciplined modular monoliths to eliminate distributed system overhead—including network latency, data consistency defects, observability sprawl, and container orchestration overhead—for teams with fewer than 100 engineers. A modular monolith enforces strict domain boundaries in a single deployment unit, significantly reducing infrastructure costs and accelerating delivery velocity until organizational scale mandates service extraction.

---

The 2026 Architectural Inflection Point: The Hangover of Premature Decomposition

Between 2015 and 2022, the software industry underwent an uncritical migration toward microservices. Startups with twelve engineers, modest traffic, and evolving product-market fit eagerly adopted the distributed architectures popularized by Netflix, Amazon, and Uber. Teams decomposed simple business applications into dozens of independently deployable services, orchestrated by Kubernetes, bound by gRPC or REST APIs, and wired through Apache Kafka.

By 2026, that architectural shift has created widespread industry reckoning. The phrase monolith to microservices regret is now a frequent theme in CTO forums, engineering retrospectives, and boardrooms. In an economic environment where capital efficiency, rapid feature delivery, and operational leanliness dictate survival, the distributed system tax has become untenable for early-stage and growth-stage companies.

Microservices were designed to resolve an organizational coordination bottleneck, not a technical execution bottleneck. When an enterprise reaches 500+ engineers, teams step on each other's toes within a shared codebase, creating deployment contention. Splitting the system into autonomous services allows decoupled teams to deploy code without cross-departmental alignment.

However, when applied prematurely to teams under 100 engineers, microservices introduce severe architectural liabilities without conferring organizational advantages. In response, modern engineering leadership in 2026 is driving a decisive migration toward the modular monolith: an architecture that preserves domain isolation, clear boundaries, and team autonomy within a single, highly performant deployment artifact.

---

Deconstructing Distributed System Overhead: The Hidden Operational Taxes

When analyzing microservices vs modular monolith 2026, engineering leaders must look past whiteboard diagrams and quantify the real-world operational taxes of distributed networks. Every time an in-memory method invocation is converted into an external network boundary, severe distributed system overhead emerges across four primary vectors.

1. Network Latency and the Multi-Hop Request Cascade

In a modular monolith, communication between two domain modules—such as OrderService querying InventoryModule—is an in-memory function call executed directly on the CPU. According to standard systems architecture benchmarks documented in Peter Norvig's canonical computing reference, Latency Numbers Every Programmer Should Know, in-process execution and main memory references operate on nanosecond timescales (approximately 2 to 10 nanoseconds for function dispatch and 50 to 100 nanoseconds for memory access), with zero serialization, zero context switching, and zero protocol overhead.

In a microservices architecture, that same operation requires:

1. Allocating memory for a request payload.

2. Serializing the object to JSON or Protocol Buffers.

3. Leasing a TCP connection over HTTP/2 or gRPC.

4. Performing TLS negotiation and encryption.

5. Traversing software-defined networks, Kubernetes ingress controllers, and service mesh sidecars (such as Envoy).

6. Deserializing the payload in the downstream pod.

7. Executing the logic and repeating the entire journey in reverse for the response.

While intra-datacenter round-trip network pings require approximately 0.5 milliseconds, full application-layer request-response cycles across modern microservices commonly measure 3 to 15 milliseconds per network hop—thousands of times slower than an in-process invocation.

More damaging than baseline latency is tail latency amplification. User-facing web requests frequently fan out into multiple downstream services. If a single page load triggers calls across 12 downstream microservices, each with a 99th percentile (p99) latency SLA of 1%, the mathematical probability that the user experiences p99 latency or worse is calculated as:

$$P(\text{System p99}) = 1 - (1 - 0.01)^{12} \approx 11.36\%$$

In a graph of 30 microservices, the compound probability of tail latency expands sharply:

$$P(\text{System p99}) = 1 - (1 - 0.01)^{30} \approx 26.03\%$$

Over 26% of user requests experience p99 tail latency. To combat this, teams introduce distributed caches, complex circuit breakers, and aggressive timeouts, which frequently introduce cache invalidation bugs and cascading fallback failures.

2. Distributed Tracing and the Observability Tax

Debugging an error in a modular monolith requires inspecting a single, coherent stack trace with localized log context. In contrast, tracing requests through a distributed mesh demands extensive distributed tracing infrastructure.

Engineering teams must adopt OpenTelemetry, configure W3C traceparent context propagation across all HTTP headers and asynchronous message queues, and deploy distributed telemetry collectors. This introduces the Sampling Dilemma:

• 100% Trace Sampling: Captures every anomaly, but generates massive ingestion and storage bills. In microservice architectures, telemetry ingestion volume scales quadratically with inter-service call depth. As analyzed across cloud-native infrastructure audits, application performance monitoring (APM) and distributed tracing invoices from vendors like Datadog, Honeycomb, or New Relic frequently expand faster than the underlying compute workload, at times rivaling core compute line items when unmanaged high-frequency sampling is deployed across dozens of services.
• 1%–5% Trace Sampling: Reduces telemetry vendor costs, but almost guarantees that rare, high-severity p99.9 latency spikes and race conditions vanish without a trace, leaving on-call engineers blind during customer outages.

When asynchronous message brokers like Kafka are introduced, context propagation often breaks entirely if a message producer fails to serialize tracing headers correctly, severing the audit trail mid-transaction.

3. Kubernetes Maintenance and Infrastructure Sprawl

Running microservices in production almost universally obligates the engineering team to maintain Kubernetes clusters (EKS, GKE, AKS) or complex container orchestration layers.

The maintenance burden is non-trivial:

• Lifecycle Upgrades: Kubernetes releases minor versions every four months. Teams spend weeks every quarter updating API versions, testing node pool upgrades, migrating Helm charts, and ensuring ingress controllers do not drop connections during rolling rollouts.
• The Sidecar Tax: When running service meshes like Istio or Linkerd to handle mTLS and traffic splitting, every single application pod runs an Envoy sidecar proxy. According to the official Istio Performance and Scalability documentation, the default Envoy proxy sidecar (istio-proxy) requires allocated baseline resources of 0.1 to 0.5 vCPU and 50MB to 128MB+ of memory per container, scaling upwards with request concurrency and the total number of service endpoints in the mesh. In a system with 30 microservices running 3 replicas across staging and production, 180+ sidecars idle continuously, consuming gigabytes of memory and multiple dedicated CPU cores purely to route localhost traffic.
• Cross-AZ Egress Costs: According to official AWS EC2 On-Demand Pricing, AWS charges $0.01 per gigabyte for data transferred in and out between EC2 instances in different Availability Zones within the same region ($0.02 per gigabyte round-trip). Similarly, Google Cloud Platform's VPC Network Pricing bills inter-zone egress at $0.01 per gigabyte within the same region. When microservices chat continuously across cluster nodes scattered across multiple AZs for high availability, cross-AZ egress fees become an invisible line item draining engineering budgets.

4. Multi-Service CI/CD Pipelines and Deployment Gridlock

Advocates of microservices cite "independent deployability" as the primary operational advantage. In practice, early-stage startups encounter orchestrated deployment gridlock.

Features rarely touch a single microservice in isolation; business initiatives invariably require changes to the user interface, the API gateway, the domain service, and the notification engine. If Service A depends on a new schema field emitted by Service B, developers cannot deploy independently:

• Teams must introduce contract testing frameworks like Pact to verify API boundaries.
• Releases require multi-stage rollouts: deploy Service B with backward compatibility, deploy Service A, verify stability, and then deploy a third cleanup release to remove deprecated fields.
• Local developer environments collapse. Running 25 Docker containers on an engineer's workstation consumes all available RAM, causes thermal throttling, and turns local debugging into a nightmare of mocked dependencies and out-of-sync database seed data.

---

Architectural Blueprint: What a Disciplined Modular Monolith Looks Like

A modular monolith is not a return to the chaotic, tightly coupled "Big Ball of Mud" architectures of the past. It is an intentional, highly structured design pattern that enforces domain separation at compile time while maintaining a single runtime binary and a unified database instance.

Core Architectural Structure

+-----------------------------------------------------------------------------------+
|                        MODULAR MONOLITH RUNTIME BLUEPRINT                         |
+-----------------------------------------------------------------------------------+
|  [ HTTP Controllers / GraphQL Resolvers / API Entrypoints ]                       |
|         |                                            |                            |
|         v                                            v                            |
|  +-------------------------------+         +-------------------------------+      |
|  |   MODULE: IDENTITY            |         |   MODULE: BILLING             |      |
|  |  +-------------------------+  |         |  +-------------------------+  |      |
|  |  | Public API / Interface  |  |         |  | Public API / Interface  |  |      |
|  |  +-------------------------+  |         |  +-------------------------+  |      |
|  |              |                |         |              |                |      |
|  |  [ Private Domain Logic ]     |         |  [ Private Domain Logic ]     |      |
|  |  [ Private Repository ]       |         |  [ Private Repository ]       |      |
|  +-------------------------------+         +-------------------------------+      |
|              \                                              /                     |
|               +----------------------+---------------------+                      |
|                                      v                                            |
|                  [ In-Memory Domain Event Bus / Channels ]                        |
+-----------------------------------------------------------------------------------+
|                             LOGICAL STORAGE BOUNDARY                              |
|  PostgreSQL Database (Single Managed Instance)                                    |
|  - Schema `identity.*` (Users, Credentials)                                       |
|  - Schema `billing.*`  (Invoices, Subscriptions)                                  |
|  * Strictly NO cross-schema foreign keys or cross-schema SQL JOIN queries *       |
+-----------------------------------------------------------------------------------+

Boundary Enforcement Mechanisms

The primary risk of a monolith is structural decay: engineers taking shortcuts, importing internal classes across domain boundaries, and creating circular dependencies. In a modern modular monolith, domain boundaries are strictly guarded:

1. Package Visibility & Internal Packages: Languages such as Go provide native internal/ package rules that prevent external packages from importing private implementations. In TypeScript, monorepo workspaces (pnpm/Turborepo) or project references isolate modules. In Java or Kotlin, tools like ArchUnit enforce architectural rules during automated builds, failing CI if the BillingModule attempts to import an internal repository from IdentityModule.

2. Static Boundary Linters: Tools like Packwerk, developed and used by Shopify, inspect code dependencies against boundary rules:

#--- package.yml: Enforcing module boundaries with Packwerk ---
enforce_dependencies: true
enforce_privacy: true
dependencies:
  - 'packages/identity'

3. Public API Contracts: Each module exposes only an immutable interface or facade alongside Data Transfer Objects (DTOs). All internal domain entities, repository interfaces, and business logic remain strictly unexported.

4. In-Memory Event Bus: When decoupling is required between modules, communication occurs via asynchronous in-memory event dispatchers (e.g., Spring Application Events, Go channels, or MediatR in .NET). This eliminates Kafka infrastructure while preserving loose coupling and clean event-driven architecture.

Logical Schema Isolation in a Unified Database

Rather than provisioning twelve separate PostgreSQL databases—which requires managing connection pools, read replicas, and migration tooling for each—a disciplined modular monolith utilizes logical schema separation within a single managed database cluster:

-- Logical Schema Segregation in PostgreSQL
CREATE SCHEMA identity;
CREATE SCHEMA billing;

-- Module: Identity owns identity tables
CREATE TABLE identity.users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Module: Billing owns billing tables
CREATE TABLE billing.subscriptions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL, -- Logical reference only, NO cross-schema foreign key!
    tier VARCHAR(50) NOT NULL,
    status VARCHAR(50) NOT NULL
);

By explicitly forbidding cross-schema foreign keys and cross-schema SQL JOIN queries, each module operates as if it owns an isolated database. If a specific domain ever outgrows the monolith and requires its own physical database in the future, extracting it requires zero schema refactoring.

---

When a Disciplined Modular Monolith Accelerates Engineering Velocity

The core justification for consolidating into a modular monolith centers on engineering throughput. The primary modular monolith benefits manifest directly in day-to-day developer productivity, eliminating friction across the entire software delivery lifecycle.

1. Rapid Local Workstation Onboarding

In a microservices organization, onboarding a new software engineer takes days of configuring Docker containers, debugging local networking scripts, provisioning mock API keys, and troubleshooting Kubernetes contexts.

In a modular monolith, onboarding is streamlined:

git clone git@github.com:organization/core-platform.git
cd core-platform
docker compose up -d postgres redis
go run ./cmd/server

The developer has an operational, testable environment running on their local workstation within minutes.

2. Comprehensive Compiler-Enforced Refactoring

When modifying an API in a microservices ecosystem, refactoring is high-risk. Changing a field name requires manual auditing of OpenAPI contracts across downstream repositories, running distributed integration tests, and hoping runtime deserialization does not fail silently in production.

In a modular monolith written in a statically typed language (Go, TypeScript, Rust, C#, Java), renaming a method or updating a domain model triggers immediate compiler feedback. The developer’s IDE updates all references across all modules in a single atomic commit. Breaking changes are caught in milliseconds inside the editor, rather than during a production canary deployment.

3. ACID Guarantees Over Distributed Sagas

Consider a common commercial workflow: a user purchases a subscription, requiring an account update, an invoice record, and an inventory decrement.

In microservices, executing this workflow across three independent databases forces teams to implement the Saga Pattern:

• An orchestrator sends an event to the Billing Service.
• If the Inventory Service fails, compensating transactions must be fired to undo the billing transaction.
• If a network partition strikes during compensation, the system enters an inconsistent state, requiring manual administrative reconciliation scripts.

In a modular monolith, the entire workflow executes inside a standard PostgreSQL database transaction:

// Atomic Transaction in a Single Database
err := db.Transaction(func(tx *sqlx.Tx) error {
    if err := identityRepo.WithTx(tx).UpdateStatus(userID, "active"); err != nil {
        return err // Automatic rollback
    }
    if err := billingRepo.WithTx(tx).CreateInvoice(invoice); err != nil {
        return err // Automatic rollback
    }
    return nil // Atomic commit across all affected tables
})

ACID transactions eliminate entire classes of distributed data corruption bugs, saving engineering teams hundreds of hours of debugging and maintenance.

---

Exhaustive Architectural Comparison: Microservices vs Modular Monolith

The following matrix provides an objective, data-driven evaluation across six primary criteria and two operational indicators.

---

Monolith to Microservices Regret: Edge-Case Failure Modes

Engineering teams that rush into microservices invariably collide with three critical architectural failure modes.

Failure Mode 1: The Distributed Monolith

The most prevalent pathology in software engineering is the Distributed Monolith: a system that suffers from all the network latency, operational overhead, and failure points of microservices, while retaining all the tight coupling and coordinated release locks of a monolithic codebase.

This occurs when:

• Services share database tables or query each other's databases directly.
• Changes in Service A require lockstep, synchronized deployments of Service B and Service C to avoid breaking runtime contracts.
• Synchronous HTTP chains link services together: if Service D experiences high latency, Services A, B, and C exhaust their connection pools and crash simultaneously.

Teams end up with an unmaintainable system that is fragile over the network yet impossible to deploy independently.

Failure Mode 2: Dual-Write Inconsistencies and the Overhead of Sagas

When an application must update a database and publish a notification event to a message broker (e.g., Kafka or SQS), network reality introduces the Dual-Write Problem. If the service crashes or encounters a network partition after committing to the database but before publishing to the broker, downstream services never receive the event.

Solving this requires implementing the Transactional Outbox Pattern: writing events to an outbox table within the same database transaction, and running a separate background process (such as Debezium or an asynchronous poller) to tail the transaction log and publish to the message broker.

While theoretically sound, maintaining outbox infrastructure across thirty independent microservices introduces massive operational fragility, schema migration friction, and disk storage overhead. In a modular monolith, this entire problem space evaporates: the event is dispatched in-memory within the verified database transaction.

Real-World Precedents: Industry Leaders Consolidating Architecture

The movement toward architectural consolidation is backed by high-profile enterprise case studies:

• Amazon Prime Video: In a landmark engineering post-mortem authored by Marcin Kolny, "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%" published on the official Prime Video Tech Blog (March 2023), the Prime Video team detailed replacing a distributed microservices architecture orchestrated by AWS Step Functions and AWS Lambda with a consolidated monolithic process running on Amazon EC2 and Amazon ECS. The architectural consolidation eliminated intermediate Amazon S3 data transfers and Step Functions state transitions, yielding a verified 90% reduction in infrastructure operating costs and immediately eliminating scaling limits.
• Segment: In the landmark retrospective "Goodbye Microservices: From 100s of problem child services to 1 superstar service" published on the Segment Engineering Blog (July 2018), Principal Engineer Alex Noonan documented how Segment had decomposed its core destination data pipeline into over 140 individual microservices. The architecture generated extreme maintenance gridlock, shared-library dependency drift, and crippling developer fatigue. Segment consolidated the 140+ destination services back into a single monolithic worker application named Centrifuge, restoring system stability and dramatically increasing product engineering velocity.
• Shopify: Operating as one of the largest e-commerce platforms globally—reporting $235.9 billion in Gross Merchandise Volume (GMV) in its 2023 Form 40-F annual report filed with the U.S. Securities and Exchange Commission (SEC)—Shopify has intentionally retained and refined a massive modular monolith running on Ruby on Rails and MySQL. As detailed by Kirsten Westeinde in "Under the Hood: Building Shopify's Modular Monolith", Shopify created the open-source static analysis engine Packwerk to enforce strict boundary encapsulation, dependency controls, and domain privacy without splitting the core application into independent microservices.

---

The Reverse Strangler Fig: Methodical Consolidation Blueprint

For organizations currently suffering from microservice fragmentation, abandoning microservices does not require an immediate, high-risk rewrite. Instead, teams apply the Reverse Strangler Fig Pattern, incrementally absorbing independent services back into a centralized modular monolith.

+-----------------------------------------------------------------------------------+
|               THE REVERSE STRANGLER FIG CONSOLIDATION PHASES                      |
+-----------------------------------------------------------------------------------+
| Phase 1: In-Process Client Facades                                                |
|   Map existing external HTTP/gRPC clients to standardized internal interfaces.    |
|                                                                                   |
| Phase 2: Codebase Ingestion (Monorepo Unification)                                 |
|   Import service source trees into bounded module directories under one project.  |
|                                                                                   |
| Phase 3: Swap Network Transport for Direct Memory Invocations                     |
|   Replace HTTP transport layer with direct in-process interface bindings.         |
|                                                                                   |
| Phase 4: Database Logical Consolidation                                           |
|   Migrate disparate RDS instances into schemas within a primary PostgreSQL DB.    |
|                                                                                   |
| Phase 5: Infrastructure Decommissioning                                           |
|   Tear down EKS clusters, Envoy sidecars, and auxiliary message queues.          |
+-----------------------------------------------------------------------------------+

Phase 1: Establish Strict Interface Facades

Before moving code, standardize the network client in the consuming application. If the OrderService calls the ShippingService over HTTP, wrap the HTTP client inside a clean interface:

type ShippingProvider interface {
    CalculateRates(ctx context.Context, payload ShippingPayload) (*ShippingRates, error)
}

Phase 2: Ingest Code into a Unified Modular Structure

Migrate the source code of the satellite service into an isolated module directory within the monolithic repository. Implement the existing ShippingProvider interface using direct, in-process method calls instead of HTTP requests.

Phase 3: Logical Database Consolidation

Consolidate the satellite service's database into the main database cluster using PostgreSQL foreign data wrappers (postgres_fdw) or standard pg_dump/pg_restore scripts into an isolated logical schema. Update the module’s data access layer to point to the shared connection pool.

Phase 4: Decommission Auxiliary Cloud Infrastructure

Once network traffic ceases flowing between the two services, tear down the redundant Kubernetes deployments, load balancers, VPC peering connections, and Datadog APM monitors.

Teams that find themselves overwhelmed by the operational overhead of fragmented cloud infrastructure often engage specialized technical advisors. Utilizing expert cloud and DevOps engineering services allows leadership to audit their existing infrastructure footprint, establish automated CI/CD pipelines, and systematically execute consolidation roadmaps without service disruption.

---

The Pragmatic Decision Rubric: When Are Microservices Actually Warranted?

A modular monolith should be the default architecture for any software organization starting a new initiative or operating with fewer than 100 engineers. However, microservices remain a legitimate, highly effective architectural pattern under specific, measurable conditions.

CTOs should only justify breaking out an independent microservice when at least one of the following criteria is met:

1. Radically Asymmetric Hardware Requirements: If 98% of your application handles standard HTTP transactions, but 2% executes intensive machine learning inference requiring high-end NVIDIA GPUs, hosting both in the same container wastes expensive compute. Extracting an isolated ML worker service that consumes tasks from an asynchronous queue is architecturally sound.

2. Scoped Compliance and Regulatory Perimeters: Under compliance frameworks such as the Payment Card Industry Data Security Standard (PCI-DSS v4.0) and Health Insurance Portability and Accountability Act (HIPAA) Security Rule guidelines, isolating workloads that process cardholder data or electronic protected health information (ePHI) into dedicated, network-segmented VPCs or separate cloud accounts is a standard infrastructure practice. This isolation minimizes the defined Cardholder Data Environment (CDE) or compliance audit perimeter, allowing organizations to avoid subjecting non-sensitive application modules to high-overhead compliance controls.

3. Conway's Law at Enterprise Scale: When an engineering department scales past 150–200 developers organized into autonomous business units with completely disparate roadmaps, cross-team coordination overhead in a single repository can degrade release velocity. At this stage, service boundaries map directly to organizational boundaries.

If your system does not meet these specific criteria, decomposing your architecture into microservices creates technical complexity without delivering tangible business value.

---

Frequently Asked Questions

Doesn't a modular monolith make scaling individual high-traffic components impossible?

No. In modern cloud environments, horizontal scaling is straightforward. If a modular monolith experiences heavy traffic on a specific set of endpoints, you scale the entire monolith horizontally across additional containers or virtual machines behind a load balancer. Because compute instances are stateless and modern applications have small memory footprints, running additional replicas of the entire binary costs a tiny fraction of the engineering hours required to manage, monitor, and deploy thirty separate microservice clusters.

How do you prevent a modular monolith from decaying into a tangled codebase?

Codebase decay is prevented through automated architectural testing and structural enforcement tools integrated directly into CI/CD pipelines. Using tools like ArchUnit for the JVM, Packwerk for Ruby and TypeScript, or Go's native internal packaging system, teams define explicit dependency rules between modules. If an engineer attempts to directly query a private domain model or bypass another module's public interface, the automated build fails immediately. Architecture is enforced by deterministic tooling, not code review discipline alone.

Will consolidating microservices into a modular monolith require a ground-up rewrite?

No. By following the Reverse Strangler Fig pattern, teams consolidate services incrementally. You begin by wrapping existing remote RPC/HTTP clients with clean interface adapters. Next, you import the service code into your primary monorepo as an isolated internal module, swapping the network client for an in-memory implementation. Database migrations are conducted logically using schema segregation within a single managed database. The system remains fully operational and deployable at every phase of the consolidation.

How does team autonomy work in a modular monolith compared to independent microservices?

Team autonomy is achieved through monorepo code ownership conventions and modern version control workflows. Using tools like GitHub CODEOWNERS, organizations assign specific teams exclusive review authority over distinct module directories (e.g., src/modules/billing/). Teams can independently develop, test, and refactor their isolated modules without interference. Integration testing runs across the entire project in CI, ensuring that contract breakages are detected before code reaches production environments.

---

Sources

• Marcin Kolny (March 2023) - Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% (Prime Video Tech Blog)
• Alex Noonan (July 2018) - Goodbye Microservices: From 100s of problem child services to 1 superstar service (Segment Engineering Blog)
• Kirsten Westeinde (September 2019) - Under the Hood: Building Shopify's Modular Monolith (Shopify Engineering)
• Shopify Inc. (February 2024) - Form 40-F Annual Report: 2023 Financial Results and GMV (U.S. Securities and Exchange Commission)
• Istio Project (2024) - Performance and Scalability: Sidecar Resource Consumption Benchmarks
• Amazon Web Services (2024) - Amazon EC2 On-Demand Pricing: Data Transfer Rates
• Google Cloud Platform (2024) - Virtual Private Cloud (VPC) Network Pricing: Inter-Zone Egress
• Peter Norvig & Jeff Dean - Latency Numbers Every Programmer Should Know (Teach Yourself Programming in Ten Years)
• PCI Security Standards Council (2022/2024) - Payment Card Industry (PCI) Data Security Standard v4.0 Scope and Network Segmentation Guidelines