Explore insights on real-time edge computing, AI, and cloud solutions. Learn how our technology optimizes performance across industries.

Blog

The code for this trading bot is open source. You can access it here: 

https://github.com/Macrometacorp/tutorial-cryptotrading

If you're going to try this project or customize it for your own strategy, you're going to need a Macrometa account. Take a minute to sign up for a free account by clicking on the button below.

I've been fortunate to have had a professional life that has exposed me to many experiences. I've not just tried my hand at software architecture and engineering, but also have been a full time professional quantitative trader for many years. The majority of my trading was with Index and Currency futures on Chicago Mercantile Exchange (CME), as well as trading US equities.

The general excitement surrounding cryptocurrencies piqued my interest. There are ~267 cryptocurrency trading exchanges spread around the world with probably around 8-10 exchanges with enough liquidity and reputation that one might consider working with them. Given the number of exchanges and volatility of cryptocurrencies, I wanted to see if it is feasible to build a trading bot that can trade on various exchanges doing something like exchange arbitrage.

An exchange arbitrage is basically a trading strategy based on the differences between the price of the cryptocurrency at different exchanges. Generally these opportunities open up if there is a price discrepancy and the discrepancy accumulates over time to finally become a significant amount like 1–3% at the cryptocurrency market. These arbitrage opportunities could exist for merely seconds, so an arbitrage trader would have to search for the best opportunities constantly and then implement them whenever possible.

Implementing arbitrage strategies in the crypto market is not that easy though, and involves a number of technical complexities. Besides having deposits in multiple major exchanges, on the technical side it involves the ability to monitor arbitrage opportunities simultaneously, making trades locally at each exchange with minimum delay and timely visibility & interactions between the trading agents distributed globally. The challenge requires big dollars and a team with the necessary technical expertise to build this type of distributed infrastructure.

Real-time crypto price data with Macrometa

 that offers a decentralized, distributed database, 

 engine and compute platform that runs across 175 global edge regions. Apps, APIs and web services written on Macrometa are automatically deployed globally and handle requests from the closest edge location relative to the request with local read-write latencies (i.e. very low latencies).

Macrometa offers a range of ready-made capabilities that enable an application like a crypto trading bot to be built quickly and easily. We will use the following features of Macrometa in this tutorial:


, decentralized and geo distributed developer platform that provides a database, a stream engine and stream processor and a function/container runtime.

 for storing trade data and sharing all trade related metadata and state between the decentralized, stateless bots and components

We will use geo distributed streams for publishing real-time price data from each exchange. Each bot subscribes to the stream and makes a decision on whether to buy or sell

Finally we will use real-time updates from the global database to automatically notify the clients/bots/subscribers of changes to the database so they can modify their trading strategy

So with the features listed above, I set out to see if Macrometa can be used to build a crypto trading bot to trade locally in multiple exchanges while providing global visibility & communication.

Some disclaimers before we proceed further - the trading strategy is an example of the capabilities of the Macrometa platform. Also, at present I do not trade cryptocurrencies. Trading involves significant risks, so always perform your due diligence. Please remember this post is about how to use the Macrometa platform and not about how or what to trade. T

his post is not to be used as trading advice or financial guidance.

For this tutorial, lets use a simple trend trading strategy:

The trading bot will run this strategy with:

Please note that the trading strategy is a hypothetical example and does not take into account slippage, spreads, position sizing, account balances etc. Feel free to enhance the strategy and let me know what the results look like. The code for this trading bot is open source.

The Crypto Arbitrage Trading Bot in Action

You can access the GUI for the single page app here - 

Clicking on above link should show something like what you see below.

For now go with defaults and click Confirm.

Once you click Confirm, the next screen will ask you to select the region for the dashboard to connect to. Currently this demo is running in 4 regions. Pick a region that is closest to you geographically.

Once you click Confirm, you will see a realtime dashboard like what is seen below.

Each of the charts in above picture represent the cryptocurrency pair quotes, its moving average and the exchange the quotes are from. This is served from the geo-replicated streams I mentioned before. The bot uses 1 geo-replicated stream per currency pair and exchange.

The bottom panel shows the trades made by the bot at each of the exchanges in that region. The panel is updated in realtime as the trades are made. You can use the filter box to filter the trades.

Now that you have an idea of what the dashboard looks like, it is time to dive into the nitty-gritty of the trading bot and dashboard code.

The trading bot uses geo-replicated streams in Macrometa's platform to publish local cryptocurrency quotes & moving averages in each region, and subscribe to the quotes and moving averages from other regions. Geo-replicated streams enable you to publish in any region and subscribe in any other region.

Similarly it uses the real-time database features of Macrometa to record trades locally in each region which are then automatically geo-replicated globally and visible to all regions in real-time. Most databases are single region and pull based in nature. Macrometa's database is geo-distributed and enables both pull and push based updates. The idea is each trading bot subscribe for updates on the trades collection (table) in each region to get updates in real-time.

Finally, the GUI is a small single page app that you can connect locally in any region and subscribe to the geo-replicated streams and trades collection to get a global view in realtime.

Building the global trading bot and dashboard wasn't as difficult as you'd think.The platform abstracts many of the complexities associated with distributed systems. As a developer, you can focus more on writing apps talking to a local system (for example, the trading bot & dashboard).

The source code is available on GitHub. You can access it here: 

Originally the trading bot was developed to run in 3 geo-locations (i.e., 3 instances) where each instance connects to one exchange locally, does the trades and publishes on respective geo-replicated streams and database. To make demos easier, we subsequently changed the code so that a single instance of the bot connects to all 3 exchanges and does the trades, while still publishing on respective geo-replicated streams.

The trading bot was developed in python using pyC8 driver (Macrometa's python driver). To make demos easier we changed the code to javascript using jsC8 (Macrometa's javascript driver).

 the details as to how to compile and run the trading bot and dashboard locally as well as via S3. 

This Crypto currency trading demo has two parts:

A UI dashboard application written in ReactJS

The node application has four main files:

 - Contains the Macrometa credentials to use for the demo.

 - The initialization work for jsc8 and streams is in this file.

 - This file gets the latest values from different exchanges and publishes them to their respective geo-replicated streams. It uses 

 library to connect to various exchanges.

 - This file subscribes to the streams, calculates the moving average to respective geo-replicated streams. Also, it triggers Buy and Sell trades and records them in the trades collection.

The demo creates two geo-replicated streams for each cryptocurrency pair it trades:

BTC/USD — cryto-trader-quotes-USD and crypto-tader-quotes-avg-USD streams

BTC/EUR — cryto-trader-quotes-EUR and crypto-tader-quotes-avg-EUR streams

BTC/JPY — cryto-trader-quotes-JPY and crypto-tader-quotes-avg-JPY streams

computes and publishes moving average to geo-replicated moving average stream

inserts a record into the trades collection.

Next are method inserts for the trade into the database feature of Macrometa's data platform.

The single page application (i.e., dashboard) subscribes to all the geo-replicated streams as well as to the trades collection to display the charts and trades in the dashboard.

This post became a lot longer than anticipated, so we're skipping the code explanation for the dashboard. Savvy javascript developers should be able to understand by looking at the code directly. You can find code for this in the below mentioned directory.

I hope you enjoyed the tutorial and can use it as a sample to write your own trading bots. Please feel free to let me know what you built and also any comments or feedback.

Finally, some unsolicited advice as a way of saying thanks for reading all the way. To me, a good trader is someone who gets checks from their broker regularly. Unfortunately for most people the checks go only in the other direction, i.e. from them to the broker. If you fall into this later category, ignore most of the stuff you read about trading. Instead, pick one simple strategy, stick to it, and paper trade until you are consistently profitable. That will be an education in patience, discipline, skill and trading mindset. Afterwards, trade with small money until you overcome the psychological challenges associated with real money on the line. That summarizes my two decades of trading experience part-time and full-time.

The code for this arbitrage trading bot is open source. You can access it here: 

How To Build A Crypto Arbitrage Trading Bot

One of the historical challenges of building real-time, distributed applications has been state. The missing piece is state – the contents of its memory that allow the application to run. Serverless has always been implied as a stateless process. So is the term "stateful serverless" a contradiction? Not anymore.

Macrometa's Justin Johnson and Redmonk analyst Kelly Fitzpatrick discuss how to build a real-time distributed application on Macrometa’s stateful serverless platform. Check out the demo below.

Build geo-distributed apps with the Macrometa CLI

What Is Stateful Serverless?

I originally wrote this in 2019, and I'm amazed at how much things have changed in just 3 years, from a technological and societal point of view. The cloud is going through a great generational shift before our eyes.

Put simply, we're now entering a new phase of the cloud where its architecture actually prevents it from solving emerging problems with data processing. The shift is from seeing and using data like its a historical record (seeing the world in the past tense), to seeing and using data as a dynamic set of events happening continuously (seeing the world in the present tense).

The cloud is built on the model of centralization: collect data from everywhere and centralize it in one big pile so that we can do something useful with it. But moving that data takes time and energy – the time cost often is latency and the energy cost is bandwidth. But there is nearly 2.5 quintillion bytes of data generated every day. By 2025, some estimate there will be 

 – all generating unbelievable amounts of data, much of it requiring real-time analysis. At this rate, the world will essentially be priced out of the centralized model.

Data needs to be ingested, processed, and analyzed where it is generated. Faster data processing requires it.

Data has time value - it tends to decay in value over time if not acted on. Data has location value when seen through the lens of ownership, privacy and data regulation. Data has concurrency value in situations where it's changing fast because of the actions of a lot of people on a common piece of data (like in auctions where the price value of something changes quickly), and finally data has actuation value - its only useful if acted on immediately (like in placing a buy order or sell order with a stock).

So take the types of data that have a mix of time, location, concurrency, and actuation value and move it to a centralized cloud model and you quickly realize the folly. The data becomes less valuable by the time it's moved and stored, it loses context by being moved, it can't be changed as quickly because all the moving around gets in the way of changing it, and finally by the time you act on it - it might be too late (your order doesn't fill in stock trades costing you profits). Therefore something has to change or evolve, that makes new assumptions about the real-time world in order for it to work. Fast data and the centralized cloud are like a race car meeting a wall at peak speeds. Lots of projectile debris and a wreck of twisted metal and rubber.

So how then do we solve this problem of fast data?

Geo-distributed fast data processing is the answer, edge computing is the architecture

Centralized cloud is the architecture of 

, but Fast Data needs its own architecture - an architecture that embraces distribution and decentralization. When we place data processing closer to the producers and consumers of data, we remove the cost of time and energy to move the data to a centralized location. The added step of analyzing this data in some central cloud is no longer necessary – we have what we need to do this at the edge. Centralized cloud at this point is a legacy system that we use despite its best efforts to stall or hinder us.

An edge architecture is not an extension of what worked in the cloud, it has to be built on the philosophy, physics, and mathematics of geo-distribution and latency. You can't simply take the primitives of data processing on the cloud-like eventually consistent object storage (S3 on AWS), clustered file storage (EBS, EFS or even lustre for that matter), high coordination overhead using consensus protocols (looking at you Paxos and Raft), and put it on the edge and expect it to work at scale. None of these systems were designed to provide high levels of accuracy (database consistency) at rapid rates of data change across large distances and a large number of locations.

Will the Edge Native Approach for Fast Data problems please stand up?

Cloud native was designed to work with the centralized cloud. We can't simply apply cloud native to our new edge architecture and expect it to work. This is a half measure. A real 

 architecture is one that is coordination free and provides high levels of accuracy on rapid rates of data change. Edge native allows developers to work with data as events – not mere state changes. This edge native architecture is event-driven, reactive to the real world and, most importantly, geo-distributed. The real edge is a brand new architecture, built on purpose specific components that solve the problems of dynamic network behavior, accurate data synchronization without the use of consensus.

The edge is a real opportunity to solve hard problems that the cloud cannot or will not solve. The edge is a hot and exciting space for new ideas, startups, and breakthrough business models. And we can expect that along with all the new interest will come inevitably, the great hordes of legacy tools vendors - rebranding their old school big data, storage and container products/services as "Now available with exciting new edge capabilities!"

Folks, we've seen that movie before. Every on-prem system vendor suddenly became cloud native with a Powerpoint slide, remember? The bar for edge computing is pretty damn high and it's not going to happen on the old cloud platforms.

Macrometa - the planet scaling, geo-distributed, fast data cloud

Macrometa provides the programming primitives for building low latency, request-response and event-driven applications for fast data.

A Global Data Network - cross region, multicloud by default with 175+ PoP locations around the world

A modern, NoSQL streaming database offering Key-Value, Documents, 

Strong and adaptive distributed consistency (accuracy) to handle various distributed concurrency scenarios

A compute runtime that lets you write event-driven code as pipelines that run with data locality across a set of user-defined locations.

Macrometa is first and foremost a platform for developers

 - its meant for people who want to solve the type of fast data problems that only edge architecture can solve. In building Macrometa - we have focused on providing the right abstractions to hide the complexity of distributed programming, accuracy and correctness. You don't need to know distributed databases or concurrent programming to write real-time, event-driven apps and APIs with Macrometa. You simply consume our APIs and let our platform do the orchestration, distribution, and scheduling of your data and code. 

Building applications the edge native way

The Great Shift - Edge Computing & Faster Data Processing

Real-time log analysis is complex and can require a huge amount of resources and tools. Having visibility of all these tools is an added challenge. At Macrometa, we give developers superpowers because we offer data storage and processing in one friendly interface. Tired of Kinesis or Splunk, or just want to explore new solutions in real-time log analytics? Macrometa and Fastly to the rescue!

Let’s talk about the technical architecture used to build a dashboard for real-time log analytics. This log analytics dashboard is part of a 

 that Macrometa recently developed with our partner 

The log analytics dashboard is composed of our 

 and Query Workers, a log capture service and a React JavaScript web app all built on Macrometa’s Global Data Network (GDN) and Fastly’s Compute@Edge. It leverages Macrometa’s pub/sub, 

, and database capabilities to ingest web logs and process them to produce real-time charts and dashboards.

The volume of logs produced by a streaming service like Netflix or Disney+ would challenge anyone tasked with creating and supporting an analytics dashboard. They may end up just hoping a superhero will swoop in and save the day. Not all heroes wear capes and Macrometa is here to save the day!

Macrometa’s platform combines a performant database with stream processing capabilities for Complex Event Processing along with a globally-distributed architecture. This allows us to process and aggregate large volumes of log data in a single bound from across the internet with very low latency and a consistent database.

This blog will describe the architecture of the log analytics application and explain the various components of the solution. We'll also give you access to the GitHub repo so you can try it our for yourself!

We have published the example log processing application code on 

 and the repo’s README includes step-by-step instructions on how to install, configure, and run the demo both locally and on Fastly’s Compute@Edge infrastructure. The application consists of Stream Workers, Query Workers, Macrometa collections, a log capture service, and a web dashboard written in React.

 is Macrometa’s stream processing framework and can be used for data processing tasks including transformation, enrichment, and aggregation.

In our Fastly log processing application, we use three stream workers. One sends HTTP requests to the Fastly service every three seconds to generate logs to analyze and the other two are responsible for reading and aggregating those Fastly web logs.

This Stream Worker uses triggers to make three HTTP requests to the Fastly service every three seconds.

This Stream worker reads Fastly logs from the `logs` collection and performs reordering for out of order logs. Based on the log timestamp, it determines the 10 second window and adds that window timestamp as an additional field.

Stream Worker Fastly-http-request-stats-1m-worker

This Stream worker reads logs from the `fastly-intermediate-stream` collection and performs windowing aggregation. It performs aggregation for response_status, url, response_body_size, and latency.

Query Workers allows developers to store parameterized Macrometa queries within the service and access them via a REST endpoint. Developers consuming data from Macrometa can thus access the data through this REST endpoint without having to provide the actual query, allowing a separation of business logic from presentation code.

Our log monitoring application uses the following Query Workers:

The dashboard in the React application is populated with the results of these queries.

Fastly pushes web logs to a Python application that inserts them into a Macrometa collection using the Macrometa Python driver. Once in the Macrometa stream collection, Stream Workers process and aggregate the logs.

The dashboard application is written in the React JavaScript framework. The react-app/src/app/services directory contains service methods that communicate with the Macrometa Query Workers to provide data for the log analytics dashboard. These methods are using the jsC8 Javascript Macrometa driver.

We'll go into more details on Stream Workers and Query Workers in future blogs. 

 and see everything you can do in one platform.

Fastly partners with Macrometa for Partner Ecosystem

Build A Real-Time Log Analytics Dashboard With Fastly And Macrometa

Macrometa is a geo-distributed streaming database with built-in compute as a service to provide low latency reads and writes to users across the globe.

In this blog, let’s build a geo-distributed, 

 Address Book application in 10 mins using our new Macrometa CLI.

 and nvm installed locally. For nvm, execute the following commands on your terminal.

Finally, run the following command to deploy the app on gh-pages

You should create an output similar to the one below.

That’s it. Now you have a low latency geo-distributed AddressBook app available to serve your users globally. The running application will look like below as shown in the video.

Typically, developers spend most a lot of their time building and wiring together various products and services to provide a globally-distributed backend. The downside of this is that they spend less time on the actual application that moves the needle for their business.

With Macrometa, the developer can spend more time on where it matters to their business and let the platform take care all the other details. The Macrometa CLI provides a convenient way to create your backend in few simple calls and integrate it into your CI/CD pipelines.

Build Geo-Distributed Apps With The New Macrometa CLI

At Macrometa, our mission is to make every developer a hero. What developers build is just as important as how they build it. Developers need their applications to perform at super low latency, even at scale. And it needs to be secure. And without all the costly infrastructure. The team at Fastly shares this vision, and that’s why we’re happy to announce that Macrometa is now a part of the Fastly Compute@Edge partner ecosystem.

Compute@Edge, Fastly’s serverless compute platform, helps developers explore new and innovative edge use cases. The partner ecosystem takes this a step further by featuring seamless integrations with other innovative companies across a wide variety of categories. Developers can now build on Compute@Edge and take advantage of Macrometa’s low-latency 

To see this integration in action, we’ve developed two sample applications built on Fastly’s Compute@Edge: A video streaming platform affectionately called Edgely + and a dashboard to track Fastly’s Real-time Log Analytics using the Macrometa 

The newest video streaming platform – Edgely +

Edgely+ from your friends at Fastly and Macrometa <3

Our video streaming platform shows what happens when you combine a super-fast, globally distributed database with Compute@Edge. Don’t just search for Keanu Reeves, refine your search by Keanu Reeves and Winona Ryder movies. There’s a few ;)

Real-time log analytics with Fastly and Macrometa

In this tutorial, learn how to use Macrometa’s pub/sub, event processing, and log analytics in real time using our Stream Workers and Query Workers (Javascript and SQL functions as a service). Ingest logs and process them to produce real-time charts and dashboards without sending any data into Splunk or Datadog (and maybe save some $$ while having fun programming for the edge). See HTTP latency, response count, response size, and unique visitor traffic - all right now.

We’re thrilled to be a part of the Compute@Edge partner ecosystem and can’t wait to see how developers build the impossible app with Fastly + Macrometa. Show us what you create by tagging us on 

Fastly Partners With Macrometa For Compute@Edge Partner Ecosystem

In 17.7, we’ve introduced a feature that allows users to create fabrics for multiple regions in the Macrometa GDN. GeoFabrics gives users more control over where their data can be stored and accessed.

In the past, new Macrometa users have had two options: access to 

 global regions or create a local collection that doesn't replicate to all regions. This had two downsides:

Not every application needs data to go to all regions, and in some cases, not all data should

Limiting to a single location/region is too restrictive

GeoFabrics give users the ability to use a subset regions, all based on their own criteria and not pre-generated (such as US, Europe, or Asia, for example). GeoFabrics helps GDN users not only comply with local data regulations (such as 

) but reduce read/write costs associated with global replication. GeoFabrics offers more options for where data should be stored/accessed, and this flexibility is offered via a simpler on/off switch. Users now have more control of data and the costs associated with reads/writes of that data. Just select the regions you need and we'll handle all of the ops. Better yet, GeoFabrics functionality is available to all users (no phone calls, emails, or signups required 😉).

When a user creates a new GeoFabric, the Macrometa GDN generates a specific global URL, and a set of regional URLs for that fabric. This fabric global URL provides geo-routing capabilities, so a request to this global URL will automatically get routed to the closest geolocation - relative to where the request was issued.

Tenant and fabric-specific URLs are essentially alias DNS records that map to the federation global/regional DNS records of the GDN. These are automatically created based on where the tenant/fabric is created. From there, all corresponding alias regional DNS records for this tenant/fabric are created on the Macrometa cloud DNS service. A unique global DNS record is created for that tenant/fabric, containing all of its alias regional DNS records, and configured with geo-location routing.

Macrometa tenant/fabric global URLs follow a specific naming convention: [name of a sea animal]-[CRC32 hash of the tenant/fabric combination + the DNS hosted zone name].

To illustrate how a tenant/fabric global URL is generated, we’ll walk through a typical tenant signup workflow and the creation of a GeoFabric spanning three locations.

 and clicking on the verification link in the confirmation email, the tenant is created along with the unique global DNS record.

Once logged in, the user is redirected to a page with their unique global tenant URL. 

Note: All edge locations are selected by default.

Now that this tenant is accessible, we can create a geo fabric for this tenant: Let’s create a fabric spanning two edge locations: on 

Upon the successful GeoFabric creation, we can see that a unique fabric global URL, along with its unique regional URLs, is also created. Notice that only two regional URLs are currently available (with toggle on), and the fabric global URL will only route requests to either edge location, based on the geolocation of the originating requests.

Fabric global/regional URLs, note the regional URL for Mumbai, India is currently disabled

There is an option to enable the third region: 

 for the fabric, effectively expanding the geo fabric to this region by creating the fabric in the Mumbai edge location, and enabling the geo-routing to the Mumbai regional URL on the fabric global URL: 

https://manta-58abf7ad.paas.macrometa.io/

The toggle button next to the now disabled Mumbai region can be switched, and it will generate a support ticket to Macrometa, notifying the platform administrator to add this region to this geo fabric on the customer’s behalf.

All of this happens in just a few steps. Watch it in action:

How does a tenant/fabric global URL work?

Overall, the tenant/fabric global URL is built on the existing federation global URL of the GDN, with its geo-routing capabilities. In addition, the global URL feature is expanded to allow the customer to create a fabric with a subset of available edge locations from the GDN, along with a unique URL for the fabric. Any request made to this unique URL will get routed to the closest location of the fabric

When a tenant/fabric is created/updated/deleted, the tenant/fabric global URLs are automatically created/updated/deleted on Macrometa cloud DNS service, along with necessary health check records, geolocation traffic policy records, etc. These DNS information are also maintained as a part system collections of GDN database.

Typical ways to generate a tenant/fabric global and its regional URLs:

During the sign up workflow of a tenant: a unique tenant global URL is generated, along with its regional URLs; customer is automatically redirected to the tenant global URL after successful login in to GDN.

Tenant global URL creation during tenant sign up workflow

Tenant creates a new fabric, and selects available edge locations for that fabric. The fabric global/regional URLs information are displayed under “GEO FABRIC” page.

Fabric global URL creation during fabric creation workflow

After a fabric is created, the tenant has the option to enable/disable a specific location for that fabric, resulting in this location being added/removed from the geo-replication; the fabric global/regional DNS records are also updated accordingly in the Macrometa cloud DNS service.

Why do we need the tenant/fabric global URL?

Many new Macrometa users didn’t need to use ALL regions provided by GDN, at least initially. Requiring them to use a static list of ALL regions added unnecessary friction for new users.

Similarly, some customers prefer to isolate the data to only certain regions for regulatory reasons. Ex: GDPR, CCP etc.

 the geo-routing capabilities of GDN. There had to be an option other than ALL or one.

The GeoFabrics feature bridges this gap: customers can use a single fabric global URL that provides geo-routing capabilities to direct the request to the region closest to them, without resorting to the current approach. With a tenant/fabric global URL, customers can get the geo-routing capabilities of the GDN without having the tenant or fabric running on 

Customers also receive a uniquely identifiable global URL per tenant, and one unique global URL per fabric created by that tenant, which can be used with the customer application, along with the GDN drivers. They can use a single tenant/fabric global URL to direct requests to the appropriate edge location, without having to resort to using any regional specific federation URL, i.e. “

GeoFabrics allow us to solve a core issue for first-time users but also allows for users to better control how and where they access their data. Having more control of data is a huge priority, not just for Macrometa users, but for everyone. We’re happy to provide this level of granularity without additional operations or infrastructure required from the user.

Data geolocation is not a new feature, and restricting data to specific regions is especially not new. What makes GeoFabrics different is that it's an improvement to our existing platform and makes the Macrometa GDN even more flexible than other solutions.

While DynamoDB has a max of 5 regions, Macrometa can provide a much bigger range, depending on your data's unique requirements

Fauna Regions allows users to restrict data to certain locations, but those regions are pre-determined (US, Europe, Asia, for example)

Google's Cloud Spanner offers multi-region support, but latency can increase with each node and data migration is...sticky, to put it mildly

 We’re a global data platform that lets users create geo-distributed databases that work in unison without any ops, and GeoFabrics help us do better at it.

Introducing GeoFabrics

In 2010, as I sat watching the FIFA World Cup with friends and family, an octopus named Paul was the topic of discussion. Paul had gained worldwide attention as an animal oracle due to its amazingly accurate predictions of the results of multiple soccer matches. I was captivated too.

The intersection with Macrometa started to happen when I thought about distributed systems, especially a 

. There are all these parallels between a good distributed system design, and the biology of an octopus: a good distributed system has a shared nothing architecture. It is highly reliable due to built-in redundancies hence no single point of failure, similar to the physiology of an octopus, which has multiple hearts and multiple brains.

Macrometa’s decentralized architecture has no single point of failure.

What's even more fascinating is that the octopus’ brain is distributed across its entire body, giving it the ability to articulate each arm independently. So, you can imagine if an octopus was a musician, it would simultaneously be able to play diametrically opposite instruments with its arms, as each one has its own brain, or dedicated processing units. This boggled my mind.

All of that processing capacity gives the octopus even more superpowers, such as camouflage. Octopus camouflage is not only limited to color blending, it can also replicate the texture of its surroundings in the most beautiful and creative ways, while also using these changes to communicate. The engineering of these uniquely intelligent cephalopods is vastly different from anything else on earth.

Just like the octopus, Macrometa’s converged multi model data platform is unique and powerful, and it delivers users superhero-like ability to develop amazing things in a fraction of the time it would take going the traditional routes. 

Our architecture is so fundamentally different from anything else that has ever been built to handle data in the cloud.

Just like the world deserved a better way to choose world cup winners, the world deserves a better way to build for the cloud. Start building your impossible application and let Macrometa be the brains in its appendages.

The Octopus And Macrometa

My professional life during the pandemic has been interesting (to say the least). Reflecting on life these past two years, I’ve realized I’ve had some amazing experiences and accomplishments: I’ve been through an acquisition, led some systems integrations, and managed a team during hyper growth. So why did I begin getting the feeling that something was missing? After some much needed introspection, I realized I was missing the joy of learning and doing something new every day.

That's why I am so excited to join Macrometa as its first Program Manager! I am also looking forward to supporting Macrometa as it grows to become the fourth cloud titan.


The largest factor for me was the culture - the people and the 

 they embody. Having experienced what an amazing, kind, and supportive work culture feels like, versus one that is overly demanding and unenjoyable, I knew I had to find the right culture fit to be happy. I could find meaningful work where I learn new things, but if the culture wasn’t right, I knew I wouldn’t be happy. 

Not only are they incredibly smart, they also truly embody the core values – Honest, Humble, Heart. The culture they create is one of trust, one of learning, and one of compassion. This is so important to me because culture lays the groundwork for how successful a company can be. I see that same culture when I meet someone new in the company.

The next important factor for me was the ability to learn and grow. Startups tend to move at the speed of light which means I also get to grow at that pace. While I don’t see myself becoming a full-time developer, I can already say I have learned a ton and I am only on Day 10. I get to learn technology and grow with the support of an amazing team.

Lastly, it’s always been important to me to be in a role where I believe in the company, the mission, and the vision. 

 is at the core of our technological future because it brings data closer to the location where it’s needed. It has such a wide range of applications from streaming services to telemedicine to autonomous vehicles. But more so, the company’s mission to “make every developer a hero” is what spoke to me. Our product will make globally-distributed app development and deployment simple and instant. I want to be a part of making that happen and leading us into the future.

I am beyond thrilled to join Macrometa on this journey!

Archive