Retailers often function in distributed application environments, with data squirreled away in databases around the country, or even the globe. It’s totally common to use different solutions for different workloads — for example, Cassandra for fast data reads with Oracle as the primary system of record. Often these different apps each do their specific job well, but getting them to talk to each other? Not so good.
This means developer teams typically have to implement workarounds (such as asynchronous replication and streaming) to get these systems in sync. This can cause two different kinds of costs for retailers: literally, by costing valuable microseconds while a transaction must jump from system to system behind the scenes before completing. And also organizationally, by consuming time and resources that their development teams could have used to build and deliver new features or improve the customer experience.
The serious challenge for retailers: simplifying distributed application data management. What would this look like?
The solution would allow distributed applications to all have equal access to the organization’s distributed data, while also guaranteeing consistency and minimizing latency. It would also provide a centralized view: From managing inventory and supply chain logistics to developing new marketing campaigns and promotions, success as an agile and aware retail organization demands a unified and easy to consume overview of all relevant data, whether transactional or analytic.
A distributed SQL database is exactly what retailers need to transform their database architecture from performance bottleneck to the engine for running and growing a successful business. The inherent advantages of pairing distributed SQL with distributed retail applications let you:
A primary goal for many retailers is simplifying your architecture. Again, as companies grow they often end up adopting multiple solutions to handle different workloads. A fairly common scenario, for example, is choosing a NoSQL solution like MongoDB for scalability and caching for real-time analytics. Unfortunately, NoSQL databases are not built for transactional data, so you also use PostgreSQL to ensure ACID-compliant transactions. But neither one of these solves a third issue: performance.
Consumers today demand a highly personalized experience, and have no patience for data loss, downtime or slow performance. Every retailer needs data solutions addressing fault tolerance and latency.
Distributing data across multiple nodes in multiple regions enables a consumer-grade experience for low-latency, real-time experiences. Storing data as close to the end user as possible helps fight latency. Capturing high availability and low latency through distributed data is what enables entertainment companies like Netflix to give people the seamless experience of enjoying their favorite movies, shows, or games wherever they are, without lagging load times or service outages.
A distributed SQL database wraps scalability, consistency and performance into a single solution — and lets retailers slim down and simplify their application architecture.
With distributed SQL, your data is replicated across regionally and globally distributed nodes, with guaranteed consistency between replicas. Every transaction in CockroachDB, for instance, guarantees ACID semantics spanning arbitrary tables and rows, even when data is distributed.
Retailers in particular are concerned with a specific flavor of consistency when it comes to payment workloads/billing systems: achieving idempotency. Idempotency means avoiding double payments on the same transaction when data is spread out across a distributed system. In other words, making multiple identical requests should have the same effect as making a single request — it is crucial a payment request gets processed completely exactly once.
Distributed SQL guarantees idempotency. It’s just part of the architecture.
Consistency, scalability, reliability, and performance are all built-in features of distributed SQL. But there is one more major benefit unique to distributed SQL that is particularly important to retailers with data nodes in different area codes: multi-region partitioning of data.
One of Distributed SQL’s most amazing capabilities is the ability to replicate across regions and selectively determine which data resides in each region.This is a powerful solution for ensuring global data protection and complying with ever-growing and varied local privacy requirements.
Any retailer serving (or aiming to serve) widely dispersed, regional and/or global customers must also respect the complex web of data sovereignty regulations that have popped up all over the world to protect data privacy. For example, any retailer selling to customers in Europe must meet the requirements of the General Data Protection Regulation (GDPR), a European Union regulation concerning data protection and privacy. GDPR forbids the export of personal data outside of EU territory, giving EU residents control of their own data. Japan has a similar data protection law, the Act on the Protection of Personal Information (APPI).
There’s no equivalent of the GDPR or APPI in the United States, which sounds like a good thing but really is not. Instead of one overall authority, retailers must instead navigate a mosaic of different state and federal rules. At the state level, some of the major efforts that require adherence include the California Consumer Privacy Act (CCPA) and the New York Stop Hacks and Improve Electronic Data Security (SHIELD) Act. Both address the data protection and privacy of their respective citizens.
Happily, it is possible to navigate this complex web of data privacy regulations with a Distributed SQL database. The solution is keeping data local and then manage it according to that locality’s rules. In other words, retailers can partition data according to location, also known as geo-partitioning. Geo-partitioning grants developers row-level replication control to say exactly where data will be stored at database, table and row levels. For example, a developer can define the physical location where every individual row is stored to satisfy whichever global privacy and compliance measures apply to that particular region.
How does geo-partitioning work? Take a retailer that predominantly does business in the U.S. and Japan, with e-commerce storefronts in both countries. The retailer could deploy a single Distributed SQL database, yet use geo-partitioning to keep the data for U.S. users in the United States and the data for their Japanese customers in Japan.
Granting retailers control over setting data location not only solves granular compliance issues — it also reduces latency by keeping user data (like PII and payment information) close to the users themselves.
However, configuring geo-partitioning in a Distributed SQL database can be fairly complex. And the whole idea is to simplify and free up your developers, right?
The good news is that the latest version of CockroachDB, 21.1, makes localizing data genuinely simple. You can control your data’s availability and latency with only a few declarative SQL statements — and then CockroachDB takes care of everything for you under the covers. This lets retailers leverage a powerful, scalable solution even with smaller tech teams to gain strong distributed performance and meet your customers wherever they are located.
Speaking of scalable…
Scaling is a major concern for retailers. Peak traffic scenarios like Black Friday or hot new product launches are always a concern. Without the proper infrastructure in place, a high volume surge of transactions can cause high latency, inconsistent data, and even downtime/outages. This means lost revenue and unhappy customers.
Distributed SQL’s architecture is designed for truly elastic horizontal scalability by evenly distributing data across database nodes and regions, responsively rebalancing as necessary. Again, however, setting up and deploying a distributed system can be complex. CockroachDB automates and abstracts away the complexity, meaning a retailer’s developer team can scale the database by simply adding new nodes and avoid any manual manipulation of data. Automatic and continuous rebalancing of data between nodes eliminates the pain of the manual sharding that is required for legacy SQL databases to achieve even nominal scalability.
CockroachDB grants automated scaling capabilities to all developer teams, no matter what their size or experience level. This enables retail organizations to grow as they need, and easily scale data across regions to deliver faster, more reliable experiences to users everywhere.
Continually improving and refining the customer experience is crucial for maintaining current customers, and acquiring new ones. You can’t do that when you have to micromanage balky applications to maintain availability, consistency, and performance. You need a solution that lets you simply deliver on your promises to customers: accurate, consistent information about inventory, delivery times, pricing, and more. Whether they are across the street or across the globe, you need a database that serves them…And informs you.
Because keeping customers and winning new ones requires one more absolutely essential service: providing personalized experiences. Shoppers simply expect a customized relationship with retailers now, and data is how to create that connection. Centralized access to metrics like purchase habits, browsing preferences, and product ratings/reviews is the foundation for offering individualized experiences to millions of global customers. Data insight lets you create strong brand stories relevant to different marketing segments for a more personalized message for each customer.
Easily accessible data gives retailers valuable information about their customers, knowledge that can be applied customer retention strategies. For example, using data like purchasing preferences, value, and frequency to generate Customer Lifetime Value (CLV) scores. If a steady high spender stops shopping or using their store cards, retailers can investigate why and create targeted strategies for re-engaging them.
Retailers use data in many different ways — functionally, strategically, creatively. You need a database that lets you view your data centrally and collectively while serving a lot of application types. It also needs to be inherently scalable, since many retail workloads are transaction heavy and can accumulate quickly. CockroachDB as a service on Cockroach Cloud lets you harness the benefits of Distributed SQL without letting complexity bog down your tech teams. Workloads that retailers use CockroachDB for today include:
Whether you run a strictly local shop or have your sights set on global domination, you need a Distributed SQL database at the core of your business. A modern database not only allows you to service your customers better; it will also prepare you to scale and meet the needs of your business whenever, and wherever, it might grow.
As a retailer, adopting Distributed SQL database lets you simplify application architecture while also increasing developer productivity. Even small tech teams can handle the complexities of distributed data with CockroachDB, eliminating manual operations and complicated configurations while ensuring optimal performance. All so they, and you, can spend time focusing on what matters: your customers.
Interested in learning more? Learn the three steps to successful retail application architecture in the cloud in Don’t Sell Your Soul to Amazon: Cloud Applications and Architectures for Retail.