E-Commerce Technology Architecture

Introduction

An e-commerce business is not merely a website connected to a payment gateway. It is a digitally coordinated business system that combines customer experience, product information, pricing, inventory, order management, payments, fulfilment, analytics, security, and partner integrations. The architecture of that system determines how quickly the firm can enter markets, modify its storefront, integrate new capabilities, withstand demand shocks, control costs, and comply with national regulations.

For an international business, architectural decisions are especially consequential. A retailer may need multiple currencies, languages, tax regimes, payment methods, delivery models, data-residency arrangements, and operating entities. An architecture suitable for a small domestic catalogue may become restrictive when the firm adds marketplaces, mobile applications, physical stores, subscriptions, or regional warehouses.

This chapter evaluates hosted, software-as-a-service (SaaS), open-source, headless, and composable architectures. It also examines APIs, microservices, cloud infrastructure, integrations, mobile commerce, performance, scalability, reliability, and technology-vendor selection. The central argument is that no architecture is universally superior. The appropriate choice depends on strategic differentiation, operational capability, regulatory exposure, integration complexity, growth uncertainty, and total cost of ownership.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish hosted, SaaS, open-source, headless, and composable commerce architectures.
2. Explain the roles of APIs, microservices, cloud infrastructure, and integration platforms.
3. Assess performance, scalability, availability, resilience, and security requirements.
4. Evaluate mobile-commerce and omnichannel technology implications.
5. Select and govern technology vendors using strategic, technical, financial, and regulatory criteria.
6. Apply architectural reasoning to an international e-commerce case.

1. Architecture as a Strategic Capability

A commerce architecture is the organized set of applications, data stores, infrastructure, interfaces, security controls, and operating processes that enable digital commerce. It has at least four layers:

• Experience layer: web storefronts, mobile applications, kiosks, social-commerce interfaces, and customer-service tools.
• Commerce capability layer: catalogue, search, pricing, promotions, cart, checkout, customer accounts, orders, subscriptions, and returns.
• Enterprise integration layer: enterprise resource planning (ERP), customer relationship management (CRM), warehouse management, payment service providers, tax engines, fraud services, marketplaces, and logistics systems.
• Infrastructure and governance layer: cloud resources, networks, databases, observability, identity management, deployment pipelines, cybersecurity, compliance, and business continuity.

Architecture creates trade-offs. Greater modularity may improve flexibility but increase integration and governance costs. A managed SaaS platform may reduce operational burden but limit deep customization. Open source may provide control but transfer responsibility for patching, security, and reliability to the buyer or implementation partner.

A useful distinction is between system of record and system of engagement. An ERP may be the authoritative system for financial inventory, while a storefront is the customer-facing system of engagement. Conflicts arise when these systems duplicate data without clear ownership. Effective architecture therefore defines data ownership, synchronization frequency, conflict-resolution rules, and service responsibilities.

2. Principal Commerce Architecture Models

2.1 Hosted and Licensed Platforms

In a hosted model, a vendor or specialist provider operates the commerce application and infrastructure for the merchant. The software may be licensed commercially and configured through vendor tools or implementation code. Hosting can be dedicated, private-cloud, or shared.

Hosted platforms typically offer greater control than pure SaaS, including access to application configuration, databases, extensions, and deployment schedules. They are suitable where the merchant needs unusual workflows, regional deployment control, or extensive integration. However, the merchant may still bear responsibility for upgrades, capacity planning, security configuration, and incident coordination.

The term “hosted” describes where software operates; it does not automatically describe the degree of customization or management. A hosted platform can be highly managed or operationally demanding.

2.2 Software as a Service

SaaS commerce platforms provide a standardized application through a subscription. The vendor normally manages infrastructure, core software upgrades, security patches, and platform availability. Merchants configure the service and use approved extensions, APIs, themes, and applications.

The principal advantage is reduced time to market and lower internal infrastructure responsibility. SaaS is attractive to firms that value predictable operations and rapid deployment. Limitations include vendor-imposed release schedules, platform-specific data models, usage-based fees, extension dependence, and possible constraints on novel business processes.

SaaS contracts require close examination. Important provisions include service-level objectives, data export, portability, termination assistance, breach notification, subprocessor disclosure, regional hosting, disaster recovery, rate limits, audit rights, and responsibility for vulnerabilities in third-party extensions.

2.3 Open-Source Commerce

Open-source platforms make source code available under a licence whose rights and obligations vary. Open source does not mean cost-free. The merchant may incur costs for implementation, custom development, hosting, upgrades, security testing, support, and skilled personnel.

Open source can support high customization and reduce dependence on a single proprietary vendor. It may also allow the organization to inspect code and build a specialized ecosystem. Conversely, extensive customization can create upgrade barriers, security exposure, and dependence on a small implementation team. Licence conditions must be assessed carefully, particularly when code is modified, redistributed, or delivered as a hosted service.

2.4 Headless Commerce

In a traditional or coupled platform, the presentation layer and commerce engine are closely integrated. In a headless architecture, the storefront is separated from the commerce back end and communicates through APIs. The same commerce services may support a website, mobile application, voice interface, in-store device, or partner channel.

Headless design provides presentation freedom, channel reuse, and the ability to adopt specialized experience technologies. It also introduces more components, API dependencies, testing requirements, caching decisions, and operational responsibilities. Headless is not automatically composable: a single commerce platform can be headless while remaining largely integrated internally.

2.5 Composable Commerce

Composable commerce assembles business capabilities from replaceable services. A firm might combine a commerce engine, a separate product-information management system, a search service, a content-management system, a payment orchestrator, a tax service, and an order-management platform.

The composable approach seeks “best fit” capabilities and independent evolution. It is valuable where customer journeys or international operating models require differentiated functionality. Its disadvantages include integration complexity, multiple contracts, inconsistent data models, distributed failure modes, and the need for strong architecture governance.

A practical comparison is shown below.

These categories can overlap. An open-source platform may be hosted, a SaaS platform may offer headless APIs, and a composable architecture may include both proprietary and open-source services.

3. APIs, Integration, and Microservices

An application programming interface (API) is a defined mechanism through which software requests data or actions from another system. APIs establish contracts concerning endpoints, inputs, outputs, authentication, errors, rate limits, and versioning. Common styles include REST, GraphQL, event-driven interfaces, and, in some enterprise settings, SOAP.

Good API design requires:

• stable resource definitions and consistent naming;
• explicit validation and meaningful error responses;
• authentication, authorization, and encryption;
• idempotency for operations that may be retried;
• versioning and deprecation policies;
• observability through logs, metrics, and traces;
• documentation and contract testing.

Idempotency means that repeating a request has the same intended effect as performing it once. It is essential for payment, order creation, and shipment requests because network failures may leave the caller uncertain whether the original request succeeded.

Synchronous APIs return a response during the request. They are appropriate when the user needs an immediate result, such as retrieving an available shipping option. Asynchronous messaging publishes an event or command for later processing. It is useful for activities such as sending an order to a warehouse, updating analytics, or notifying a loyalty system. Asynchronous systems improve decoupling but require attention to duplicate messages, ordering, delayed processing, and eventual consistency.

Microservices divide an application into independently deployable services organized around business capabilities. A catalogue service, pricing service, cart service, and order service may each own its data and release process. The architectural benefit is selective scaling and team autonomy. The cost is distributed-systems complexity: network failures, inconsistent data, operational overhead, and difficult end-to-end debugging.

Microservices should not be adopted simply because they are fashionable. A modular monolith may be more appropriate for a smaller firm. It can preserve clear internal boundaries while avoiding unnecessary network calls and deployment complexity. The choice should follow organizational scale, domain complexity, release independence, and reliability requirements.

4. Cloud Infrastructure and Data Architecture

Cloud infrastructure provides on-demand computing, storage, networking, managed databases, content-delivery networks (CDNs), identity services, monitoring, and automation. The main service models are infrastructure as a service, platform as a service, and SaaS. Public, private, and hybrid cloud arrangements differ in control, portability, cost, and regulatory implications.

A typical international storefront may use a CDN to cache static assets near customers, an application layer distributed across availability zones, managed databases, object storage for images, and queues for asynchronous work. Regional deployment can reduce latency and support data-residency requirements, but it can also complicate synchronization and disaster recovery.

Data architecture should classify information by sensitivity and purpose. Personal data, payment tokens, order records, behavioural events, product content, and operational logs have different retention, access, and residency requirements. A data lake or analytics platform should not become an uncontrolled copy of customer information. Data minimization, purpose limitation, role-based access, encryption, retention schedules, and deletion processes are architectural concerns, not merely legal paperwork.

The shared responsibility model means that the cloud provider secures the underlying service, while the customer remains responsible for configuration, identities, application code, data, and often network controls. The exact division varies by service and contract.

5. Performance, Scalability, and Reliability

Performance concerns how quickly and consistently a system responds. Important measures include latency, throughput, error rate, resource utilization, and user-perceived loading time. The average alone is insufficient; the 95th or 99th percentile may reveal slow experiences affecting a substantial customer segment.

A basic utilization relationship is often expressed through Little’s Law:

Here, L is the average number of items in a stable system, λ is the average arrival rate, and W is the average time an item spends in the system. Units must be consistent: if arrivals are measured in requests per second and response time in seconds, L is requests in the system. The relationship assumes a stable system over the observation period and is useful for reasoning about queues, requests, or orders. It does not by itself predict response-time distributions or guarantee capacity.

For a simple sequential path, approximate end-to-end latency can be represented as:

Each term represents elapsed time contributed by network transfer, application processing, database operations, and external services. The expression is an approximation; parallel calls, caching, retries, and queueing can change the relationship. It is useful for locating major contributors rather than treating latency as a fixed physical constant.

Scalability is the ability to handle increased workload. Vertical scaling increases the capacity of a component; horizontal scaling adds instances. Stateless application servers are easier to scale horizontally because requests can be routed to any healthy instance. Stateful sessions, local file storage, and shared mutable caches complicate scaling.

Reliability is the probability that a system performs correctly over a period. Availability is the proportion of agreed time that a service is usable. A simplified availability calculation is:

If a service has 43,200 minutes in a 30-day measurement period and is unavailable for 43.2 minutes, availability is 99.9%. The calculation assumes that the measurement definitions, exclusions, maintenance rules, and monitoring method are specified consistently. A high availability percentage does not necessarily mean that every transaction succeeded.

Resilience includes graceful degradation, redundancy, retries with backoff, circuit breakers, health checks, backups, failover, and tested recovery procedures. Retries must be bounded: retrying a failed payment or order request without idempotency can create duplicate business actions. Recovery objectives should be explicit:

• Recovery time objective (RTO): maximum acceptable time to restore service after disruption.
• Recovery point objective (RPO): maximum acceptable amount of data loss measured in time.

Performance engineering should begin with business journeys. Product discovery, search, cart, checkout, payment authorization, and order confirmation deserve different service objectives. A non-critical recommendation service may be disabled while checkout continues.

6. Mobile Commerce and Omnichannel Architecture

Mobile commerce is not simply desktop commerce displayed on a smaller screen. Mobile users face variable networks, limited battery, touch interaction, location permissions, and frequent use during movement. Architecture should support responsive web design, progressive web applications, native applications, or a combination.

Native applications can provide deep device integration, push notifications, biometric authentication, and offline capabilities. Progressive web applications can reduce installation friction and support broad device coverage. The choice should reflect customer behaviour, acquisition economics, update frequency, and the value of device-specific capabilities.

Mobile architecture should minimize payload size, defer non-essential resources, optimize images, protect tokens, and avoid storing sensitive information unnecessarily on the device. Mobile payments may involve wallets, tokenization, biometric confirmation, and stronger authentication requirements. Privacy notices and permission requests should be understandable and proportionate.

Omnichannel commerce connects web, mobile, stores, call centres, marketplaces, and fulfilment operations. Capabilities such as buy online, pick up in store; ship from store; unified returns; and real-time inventory require shared or synchronized customer, order, and inventory data. “Real time” should be defined operationally. An inventory value updated every few minutes may be adequate for some products but unacceptable for scarce or high-demand products.

7. Security, Privacy, and Governance

E-commerce architecture has a large attack surface: customer accounts, administrative interfaces, APIs, payment flows, third-party scripts, cloud identities, suppliers, and mobile applications. Security should be designed through defence in depth rather than a single perimeter.

Core practices include strong identity and access management, least privilege, multi-factor authentication for privileged users, secure secrets management, encryption in transit and at rest, secure software development, dependency scanning, vulnerability management, network segmentation, logging, incident response, and tested backups.

Payment-card obligations may be reduced through tokenization and use of qualified payment providers, but outsourcing does not eliminate governance responsibilities. Privacy regulation may impose requirements concerning lawful processing, transparency, consent, access, correction, deletion, cross-border transfers, breach notification, and automated decision-making. The applicable rules depend on the organization, customers, data, and jurisdictions involved.

Third-party scripts deserve special scrutiny because analytics, personalization, advertising, chat, and fraud tools can access or transmit customer data. Vendor risk management should examine subprocessors, security attestations, breach history, data use, retention, and contractual remedies.

Artificial intelligence can support search ranking, recommendations, demand forecasting, fraud detection, customer service, translation, and content generation. Its use requires attention to data quality, bias, explainability, human escalation, intellectual-property rights, prompt or training-data leakage, and model-performance monitoring. AI should be integrated as a governed capability, not treated as an exemption from privacy and security controls.

8. Vendor Selection and Total Cost of Ownership

Vendor selection should begin with business capabilities and constraints rather than product demonstrations. A weighted decision model can make assumptions visible. For criterion i, a simple score is:

Here, w_i is the normalized importance weight for criterion i, r_i is the vendor rating on a common scale, and S is the weighted score. The method assumes criteria are sufficiently defined, ratings are comparable, and the weights reflect strategic priorities. It supports discussion but does not eliminate judgement or compensate for a fatal weakness in security or compliance.

Typical criteria include:

Total cost of ownership includes direct and indirect costs: subscription or licence fees, implementation, custom development, integration, cloud consumption, support, testing, security, training, internal staff, downtime, upgrades, and eventual migration. A low initial price can conceal high customization or transaction costs.

Vendor evaluation should include proof-of-concept testing with representative catalogue size, promotions, traffic, integration failures, regional tax rules, and peak-event scenarios. Reference checks should include customers with comparable scale and international complexity. Contracts should address service levels, service credits, data export formats, ownership of custom work, subcontractors, change control, price increases, termination assistance, and business continuity.

9. Illustrative Case: Meridian Home International

Background

Meridian Home is a fictional mid-sized home-goods retailer operating in the United Kingdom, Germany, Canada, and Singapore. It sells through a website, mobile application, marketplaces, and 35 stores. Its original platform is a tightly coupled domestic system with batch inventory updates, a single payment provider, and substantial custom code.

Problem

International expansion has created slow catalogue updates, inaccurate store inventory, inconsistent tax calculations, and difficult mobile releases. During promotional events, checkout failures increase. The technology team proposes replacing the entire platform with a fully composable architecture, while the finance team prefers a managed SaaS platform.

Analysis

The business has genuine international and omnichannel complexity, but not every capability is strategically differentiating. Product discovery, localized content, inventory visibility, and fulfilment coordination are important. The firm has a small platform team and limited experience operating distributed systems. A complete microservices rewrite would create high execution risk.

The team maps capabilities and identifies systems of record. The ERP remains authoritative for financial inventory and accounting. A product-information service becomes authoritative for localized product content. The commerce platform owns carts, promotions, and customer orders until orders are handed to the order-management system. Payment authorization is delegated to a certified provider, and tax calculation is delegated to regional tax services.

Approach and Solution

Meridian selects a managed SaaS commerce core with headless APIs, a separate product-information service, a CDN, an integration platform, and an order-management service. It retains a modular monolith for selected internal functions rather than immediately creating dozens of microservices. Events are used for catalogue updates, order fulfilment, and analytics; synchronous APIs are retained for checkout decisions that require immediate responses.

The implementation uses phased migration. Germany is launched first because it tests localization, tax, payments, and fulfilment without exposing all markets simultaneously. Automated contract tests validate API behaviour. Inventory is labelled with freshness information, and the customer experience explains when store availability is approximate. A fallback payment provider is introduced only after the primary flow is stable.

Reliability objectives distinguish critical from non-critical functions. Recommendations may be unavailable without blocking checkout. Order creation uses idempotency keys. Observability tracks latency percentiles, payment errors, inventory synchronization delay, and abandoned checkout by market.

Outcome

The architecture reduces infrastructure operations and accelerates localized content releases. It does not eliminate complexity: integration monitoring, vendor management, data governance, and release coordination become more important. The phased approach avoids an unnecessarily large transformation and preserves the option to replace individual capabilities later.

Learning Points

1. Architecture should follow capabilities and strategic priorities, not fashion.
2. Headless APIs can provide channel flexibility without requiring a complete microservices transformation.
3. Clear data ownership is essential for inventory, products, customers, and orders.
4. Reliability must be designed around business journeys and failure consequences.
5. Vendor contracts and exit capabilities are part of architecture.

10. Contemporary Developments and Best Practices

Several developments are reshaping commerce architecture. Edge computing and more capable CDNs move selected processing closer to customers. Event-driven systems improve decoupling, while platform engineering provides reusable deployment and observability capabilities. Composable ecosystems are expanding, but integration governance remains a differentiator. Digital identity, wallet payments, social commerce, and conversational interfaces are increasing the number of customer touchpoints.

Best practice is not maximal technical sophistication. It is disciplined alignment between business strategy and technical risk. Organizations should:

• maintain a capability map and target architecture;
• define ownership for data and services;
• prefer the simplest architecture that satisfies strategic requirements;
• establish measurable performance, availability, RTO, and RPO objectives;
• automate testing, deployment, security checks, and infrastructure provisioning;
• design APIs and events as governed products;
• test failure scenarios, peak demand, recovery, and vendor exit;
• monitor total cost and technical debt;
• minimize personal data and control third-party access;
• review architecture as markets, channels, and regulations change.

Challenges and Limitations

Architecture frameworks can create false precision. A weighted score depends on subjective ratings, and a service-level percentage may conceal severe failures affecting particular customers. Cloud elasticity does not guarantee low cost; poorly controlled consumption can increase expenditure. Microservices do not automatically improve performance, and composability can produce a fragile network of dependencies. Open source does not remove vendor dependence because firms may rely on specialist maintainers or implementation partners.

International commerce adds unresolved tensions among centralization, local adaptation, data residency, payment preferences, tax compliance, and operational consistency. Architecture decisions should therefore be revisited through evidence: incident records, customer experience metrics, integration performance, cost trends, regulatory change, and strategic priorities.

Chapter Summary

E-commerce technology architecture coordinates customer experiences, commerce capabilities, enterprise systems, infrastructure, data, and governance. Hosted and SaaS platforms reduce operational burden to different degrees; open source offers control but requires technical ownership. Headless architecture separates experience from commerce services, while composable commerce assembles replaceable capabilities. These models overlap and should be selected according to business requirements rather than labels.

APIs, event-driven integration, and microservices can improve flexibility, but they introduce distributed-systems risks. Cloud infrastructure supports elastic capacity and global delivery, yet security, configuration, data governance, and cost remain customer responsibilities. Performance should be measured through latency, throughput, error rates, and user journeys. Reliability requires redundancy, graceful degradation, bounded retries, idempotency, observability, backups, and tested recovery.

Mobile and omnichannel commerce require shared customer, product, order, and inventory capabilities. Security and privacy must be embedded in architecture, particularly when third-party services and AI are used. Vendor selection should combine strategic fit, functional and technical evaluation, international capability, total cost of ownership, contractual governance, and exit planning. The strongest architecture is not the most complex; it is the one that provides required capabilities with governable risk and sustainable economics.

Key Terms

Architecture: The organized structure of systems, data, interfaces, infrastructure, and governance.

API: A defined interface through which software requests data or actions from another system.

Availability: The proportion of agreed service time during which a service is usable.

Composable commerce: An approach that assembles commerce capabilities from replaceable services.

CDN: A content-delivery network that distributes content closer to users.

Event-driven architecture: An architecture in which systems communicate through published events and asynchronous processing.

Headless commerce: Commerce architecture that separates the customer-facing presentation layer from the commerce back end.

Idempotency: The property that repeating an operation produces the same intended business effect as performing it once.

Microservices: Independently deployable services organized around business capabilities.

Modular monolith: A single deployable application with clearly separated internal modules.

Open source: Software distributed under a licence granting specified rights to inspect, use, modify, or redistribute code.

RPO: Recovery point objective; the maximum acceptable period of data loss after disruption.

RTO: Recovery time objective; the maximum acceptable time for service restoration.

SaaS: Software delivered and managed by a provider through a subscription service.

Scalability: The ability of a system to handle changing workload by adding or increasing resources.

System of engagement: A system primarily designed for interaction with customers, employees, or partners.

System of record: The authoritative source for a particular category of business data.

Total cost of ownership: The complete direct and indirect cost of acquiring, operating, changing, and retiring a technology.

Vendor lock-in: Dependence that makes changing suppliers technically, financially, or operationally difficult.

Review Questions

5 Short Answer Questions

1. What is the principal difference between a hosted platform and a SaaS platform?
2. Define headless commerce and identify one advantage and one risk.
3. Why is idempotency important in order and payment APIs?
4. What do RTO and RPO measure?
5. Explain the difference between a system of record and a system of engagement.

5 Long Answer Questions

1. Compare hosted, SaaS, open-source, headless, and composable architectures, including their strategic advantages and risks.
2. Explain how APIs, asynchronous events, and microservices can be combined in an international commerce architecture.
3. Discuss the relationship among performance, scalability, availability, resilience, and customer experience.
4. Evaluate the security, privacy, and governance implications of third-party integrations and cloud infrastructure.
5. Develop a vendor-selection framework for a retailer entering three new international markets.

3 Analytical / Application Questions

1. A retailer experiences checkout failures during promotions while its recommendation service remains available. Design a resilience and observability response, identifying which functions should be prioritized and why.
2. An organization is choosing between a standardized SaaS platform and a composable architecture. Construct a decision analysis using strategic differentiation, internal capability, integration complexity, regulatory exposure, and total cost of ownership.
3. Design a target architecture for an omnichannel retailer whose ERP owns financial inventory, whose stores require pickup capability, and whose mobile application must support localized payments. Specify data ownership, APIs, events, security controls, and recovery considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best describes headless commerce?

A. The commerce platform operates without a database.

B. The presentation layer is separated from the commerce back end through interfaces such as APIs.

C. All commerce capabilities are supplied by one SaaS vendor.

D. The platform can be used only through a mobile application.

Correct Answer: B. The presentation layer is separated from the commerce back end through interfaces such as APIs.

Question 2

What is the main purpose of an idempotency key in order creation?

A. To compress an order payload

B. To increase the visual quality of a storefront

C. To prevent a retried request from creating an unintended duplicate order

D. To replace customer authentication

Correct Answer: C. To prevent a retried request from creating an unintended duplicate order

Question 3

Which architecture generally places the greatest responsibility for patching and maintaining source code on the merchant or its partners?

A. Open-source architecture

B. Fully managed SaaS architecture

C. A CDN architecture

D. A payment-tokenization architecture

Correct Answer: A. Open-source architecture

Question 4

A service has 43,200 agreed minutes in a measurement period and is unavailable for 43.2 minutes. Its simplified availability is:

A. 90.0%

B. 98.0%

C. 99.0%

D. 99.9%

Correct Answer: D. 99.9%

Question 5

In the relationship L = λW, what does λ represent?

A. Average arrival rate

B. Average number of items in the system

C. Average time in the system

D. Database storage capacity

Correct Answer: A. Average arrival rate

Question 6

Which is the strongest example of a system of record?

A. A product recommendation widget

B. A social-media advertisement

C. An ERP designated as authoritative for financial inventory

D. A mobile application screen

Correct Answer: C. An ERP designated as authoritative for financial inventory

Question 7

What is a principal benefit of asynchronous messaging?

A. It guarantees that all data is immediately consistent.

B. It can decouple systems and allow non-immediate work to be processed later.

C. It eliminates the need for authentication.

D. It prevents every possible network failure.

Correct Answer: B. It can decouple systems and allow non-immediate work to be processed later.

Question 8

Which criterion is most directly related to a vendor’s ability to support market-specific operations?

A. Availability of a dark-mode theme

B. Support for local currencies, taxes, languages, and payment methods

C. The colour of the vendor’s logo

D. The number of office locations unrelated to service delivery

Correct Answer: B. Support for local currencies, taxes, languages, and payment methods

Question 9

What does RPO specify?

A. The maximum acceptable time to restore service

B. The maximum acceptable period of data loss measured in time

C. The percentage of successful page views

D. The number of microservices in an application

Correct Answer: B. The maximum acceptable period of data loss measured in time

Question 10

Why might a modular monolith be preferable to immediate microservices adoption for a small platform team?

A. It eliminates all integration requirements.

B. It provides internal modularity while avoiding some distributed-systems and operational complexity.

C. It cannot be scaled under any circumstances.

D. It guarantees lower transaction fees.

Correct Answer: B. It provides internal modularity while avoiding some distributed-systems and operational complexity.