MongoDB.local In Auckland is done and dusted for 2023, and to call it an outrageous success would almost be an understatement.

It was an incredible privilege for me to present some of my story, particularly the events that occurred in 2013 that caused me to begin my search for a better database, ultimately leading me to MongoDB.

With great power comes great responsibility

With great power comes great responsibility, and we, as software engineers, have an increasing, and probably disproportionate, influence over the success and failure of the organisations we represent and serve.

With that comes enormous opportunity and responsibility.

Our decisions as engineers and as engineering leaders have the potential to be business-critical, and through the zerospam story (a business I founded in 2006), I was able to share how a critical database failure resulted in a thriving business going out of business within three days.

We should always assume that our decisions are long-term unless we are 100% sure that we know otherwise.

You don't always know when an idea or system is going to take off. When we designed and built zerospam, we built it for what we expected the customer base to be. However, growth exceeded this, and e-mail velocity and volume vastly exceeded this.

Changing engineering decisions on systems that are running at scale is like changing a flat tyre on a vehicle travelling at 100 kilometres per hour on the motorway. It's almost impossible and almost never happens. What inevitably happens is that those engineering decisions become massive anchors that create drag and slow the business down.

Long-term decisions require careful consideration, and it was interesting that in a follow-up conversation with an experienced engineer over lunch, he commented that the more experienced he became, the more cautious he became in his decision-making because he realised the significance and the impact that those decisions would have on his organisation.

Decisions, particularly around our tech stack, have the potential to radically affect the agility, not only of our teams or engineering functions but of our entire organisations. They can equip us with the tooling to disrupt markets or serve as anchors that create massive drag and slow us down, increasing our delivery cost and ultimately giving our competitors an advantage they didn't even ask for.

The key takeaway from my presentation yesterday was that we, as engineers are deeply responsible not only for the success and failure of our systems but, at times, the success and failure of the businesses and organisations we serve.

When a building collapses, and people are injured or killed, we expect the engineers that designed and built that building to answer some questions. Shouldn't we then, in the same way, have that same expectation of ourselves when systems fail and businesses collapse and die?

I also spoke about some practical steps we've implemented at Cloudize to ensure this type of failure will not occur in our business.

Composition has always been part of good software design. However, as we abstract our level of composition and we start designing engineering solutions by composing systems from reliable, robust, secure and dependable cloud technologies, we find ourselves in a wonderful position to reduce our area of focus and expertise to our core value proposition, the thing our customers genuinely care about, the reason that our businesses exist and what our customers pay us for.

What else do my customers not directly care about?

My final challenge to the audience was never to stop asking, "What else am I doing that my customers don't directly care about?". Inevitably, there will be several things that your customers indirectly care about. These are not the things you should be building but rather present an opportunity for you to partner with organisations that have made delivering those capabilities their primary reason for existence.

If you have an idea that needs to go to the cloud, give us a call. We'd love to discuss it and how we can help.

MongoDB.local Auckland is done and dusted, and to call it an outrageous success almost seems to be an understatement.

MongoDB.local Auckland, what an incredible event!

We're delighted to share that Cloudize will be presenting at MongoDB.local in Auckland on the 17th of August.

We've been working really closely with the MongoDB team in New Zealand and Australia for the last few years, and it's going to be great to share some of our story, the events that lead us to start looking at MongoDB, and how we're better able to serve our customers as a result of the strong partnership we have with MongoDB.

If you haven't already, take a moment and <a href="https://events.mongodb.com/mongodb-local-auckland" target="_blank">register for the event</a> while there are still seats available.

Cloudize is presenting at MongoDB.local

We're delighted to share that we have released Version 23.2 of the Cloudize API Framework today.

One of the things that we're most excited about in this version is the addition of support for ARM64 processors. ARM64 compute options, such as AWS Graviton-based machines, deliver comparable performance to similar Intel-based deployments at a much better price point (± 25% cost reduction). We intend to write a more detailed blog on a head-to-head performance comparison of an API running on the two architectures within the next month or two. That said, we see ARM64 as significant and have already migrated all of our internal workloads, including our new Cloudize Platform APIs (scheduled for release by the end of Q2), to ARM64 infrastructure.

Another significant step forward included in Version 23.2 is decoupling the Cloudize API Framework from the AWS SDK. It is no secret that we initially built our technology on AWS infrastructure. While we still believe they are a brilliant choice, customers may want or need to deploy on other cloud platforms such as Azure, GCP, or elsewhere. Version 23.2 still depends on a secret manager to deliver the database connection parameters to the framework but now provides the ability for the API application itself to inject that dependency into the framework at startup. This change makes the framework cloud-agnostic and presents more choices regarding where APIs built with the framework can be deployed.

In Version 23.1, we introduced support for branch fragments within our design tooling. Branch fragments are incredibly powerful and allow for the definition of complex types within API contracts that can accept one of many definitions, each with its own validation rules and, most importantly, without needing to write any code. Version 23.2 builds on that capability by adding typed support for branch fragments within the SDK code generator. This is a huge step forward in simplifying the downstream integration of APIs that implement these potent but potentially complex structures.

In addition, several technical enhancements are also included in this release. The framework now supports Node 20. The MongoDB interface has been upgraded to the new Version 5 driver, and we've upgraded to Typescript 5. In addition, our CloudFormation templates for well-architected API deployments now support both Intel and Graviton deployments on ECS using Fargate or EC2 clusters as capacity providers.

Whilst this release has primarily been focused on giving customers more choices on infrastructure options to run the technology, we have continued to focus on code quality and simplicity within the code base, and test coverage remains in the mid-90s.

Looking ahead, we expect that version 23.3, which is scheduled for release in Q3, will be a maintenance release, with the lion's share of our effort during the next two quarters being allocated to supporting multi-cloud deployments and web-enabling our API design tooling.

In this blog article, we'll discuss the new features included in Version 23.2 of the Cloudize API Framework.

Cloudize API Framework Version 23.2 Release

Back in 2018, I worked for a large multinational software company. In that role, I led a team of extraordinary engineers that designed, built and managed one of the company's foundational platform services.

My role was essentially twofold. Firstly, as you'd expect, my primary responsibility was the team and the people within the team, and whilst I could talk for hours about my passion for good leadership, the genesis of this article is rooted in my secondary responsibility at the time, which was looking ahead, working with product management and planning the work that was likely to enter the team's workstream within the next 90 days.

Typically, it would look like this; Product management would have a feature they wanted to develop for our customers. We'd spend time discussing the details of the feature and clarifying the requirements; on occasion, architects would join the discussions to offer solution options, and finally, once everyone was on the same page, we'd go back to the team to get their high-level guesstimates on the effort required to build the feature.

That's when I noticed some cracks starting to appear.

Time and time again, the sizing provided by the development team, which is essentially the delivery cost, exceeded what product management was willing to spend on the feature.

It was an awkward stalemate, and my BA and I often found ourselves trapped right in the middle. We clearly understood and could empathise with the frustration of the product management team. However, we also knew that our development team was providing accurate estimates, so we equally empathised with them, hence the awkward stalemate.

The undeniable net result was that our customers were not getting the features the product team had painstakingly designed and developed.

This scenario played out repeatedly, and it started to have an insidious effect on the organisation. It was like a huge anchor had been thrown overboard. It didn't jolt the ship to a screeching stop but created an enormous drag, ultimately slowing the colossal vessel.

When agile teams repeatedly create value that outstrips the cost of delivery, they accelerate. Conversely, when the cost of delivery constantly exceeds the value being created, innovation is stifled en masse.

It suddenly dawned on me. We were looking at technical inefficiency. Everything was hard. The data model was hard to work with. Building world-class, secure and performant APIs was hard.

I started to visualise a better world for my team and the wider engineering organisation we were part of. A world where everything would be easy and in which we had the tooling required to design and deliver incredible APIs to our consumers effortlessly. A world where 90% of our effort could be assigned to providing solutions to actual customer problems and not on building out the core table-stakes capabilities of modern APIs.

Ultimately, as I reflect back, this was the genesis moment behind Cloudize and our low-code API Technologies.

The company had several very real near-term pressure points, and focusing on them meant there was simply no capacity to look ahead and build an API platform library that would ultimately bring efficiencies to API development processes a year or two down the line.

It was clear that if I wanted the ideas and the future state I envisioned to become a reality, I would need to do so outside the organisation. After careful consideration, I resigned and founded Cloudize to deliver the technologies required to accelerate innovation for our customers.

The bulk of the Cloudize API Framework and its related built-as-you-design technologies were built in 2021. It was a wonderful time. The business had zero pressure points, and I could focus 100% of my effort on getting the foundations of the product right. That didn't happen immediately. It took several conceptual iterations before we saw the development efficiencies that we were pursuing.

We explored building a pro-code library that developers could consume as well as a no-code platform that customers could leverage. Ultimately, we landed on a hybrid of the two, a low-code technology that massively scaled innovation whilst delivering developers the capability to integrate custom logic.

After about nine months of research and development, we achieved a critical milestone. With our new build-as-you-design tooling and Cloudize API Framework, a single engineer could, within a week, build a service that previously took seven engineers five months to create. Subsequently, in 2022, additional significant steps were made in performance, security, scalability, flexibility, and design efficiency. With these new improvements, we made another substantive step towards our goals. What previously took an engineer a week to do could now be done in a day.

The critical outcome is that the time required to go from ideation to production-grade APIs has been all but eliminated. This has massive implications concerning the ability to innovate within organisations. When the cost of delivering an idea approaches zero, we create safe-to-fail environments. As the cost of failure approaches zero, our willingness to experiment increases. When experimentation costs less, we can afford to become more creative; as a result, we start to innovate at scale and accelerate.

In this blog article, we'll share a bit about the history behind the Cloudize API Technologies and why we founded Cloudize.

The genesis story behind Cloudize and our API Technologies

Last week, I shared my journey with <a href="https://www.mongodb.com/" target="_blank">MongoDB</a> at the inaugural MongoDB User Group meeting in Auckland. At the event, I shared my top 10 tips for building high-performance applications with MongoDB, and today, I want to build on those ten points and add some flesh to the bones.

1. Use MongoDB Atlas for both dev and prod workloads.

As discussed on Thursday evening, critical database failures can potentially deliver catastrophic impacts on your business.

Unless your business explicitly specialises in running databases at scale as a core offering, I would advise you to focus on your customers and your core value proposition and deliver against that faster than your competitors can. That's what will build your business.

One of the best ways of doing that is by adopting a "build-on-the-shoulders-of-giants" mindset, and in the case of database infrastructure, there is none better than <a href="https://www.mongodb.com/atlas" target="_blank">MongoDB's Atlas</a> service.

I've heard the argument that you can self-host cheaper than subscribing to Atlas, and when you only consider actual dollars and cents, that might be true, but ask yourself at what cost;

Regarding development clusters, the cost argument doesn't stack up at all. Atlas offers the ability to pause clusters when they are not needed (for example, outside of business hours when your devs aren't working). This capability allows you to easily save 60-70% of your development cluster cost. It makes any argument against Atlas for dev clusters really difficult to justify.

Regarding production workloads, I would argue that the production-grade functionality that Atlas delivers out of the box is a solid financial argument for you to adopt the service. In short, it would take hundreds, if not thousands, of years of hosting savings to justify the development of those capabilities within your business.

Again, the question you should be asking is; are you in the business of running databases at scale, or do you use databases to deliver your core value prop to your customers?

I once worked on a system that delivered a certain resource through an API. The resource was composed of data within a relational database that spanned ten database tables. The SQL statement to join the data required was almost 200 lines long and involved multiple nested joins. Consequentially, it was difficult to achieve consistently high performance due to the complexity related to fetching the data.

Replacing the relational database in question with a document database, such as MongoDB, but retaining the data model will not make any difference. In fact, it might make it worse.

Relational thinking is suitable for relational databases. Applying relational design to a document database will disappoint you.

If I modelled that same system today, using our <a href="/technology/" target="_blank">Cloudize API Framework</a> and MongoDB, the resource would be directly related to a document in the database. Consequently, no joins would be required, and delivering single-millisecond response times would be reasonably easy to achieve at a far lower cost. Additionally, what took a team of gifted engineers months to design and develop could be done within a day.

When we remove complexity, everything gets better.

3. Use time-series collections where possible.

The need to store time series data has grown exponentially over the last decade. IoT and AI have exploded, and the need to efficiently store time series data has become imperative for many businesses. MongoDB 5.0 introduced time-series collections, and having worked with them a bit; I can honestly say that I'm impressed. Last year, as part of our production load testing of the <a href="/technology/" target="_blank">Cloudize API Framework</a>, we easily achieved over 30,000 inserts per second into a time series collection on an unsharded M30 cluster.

That's mind-blowing performance on a database that costs less than US$400 per month.

4. Look for opportunities to leverage partial and sparse indexes.

The most significant factor driving your database costs up is typically the memory required by your database.

Let me explain. At the very minimum, a database will always look to load all of your indexes into RAM in order to maximise its ability to find the data related to a query in the fastest possible way. In addition to this, it will also develop a working set in RAM, which contains records that it determines might be frequently accessed, but let's ignore this second factor for now.

One of my favourite features of MongoDB is that we can directly control the size of an index by using partial and sparse indexing.

Let me give you an example. Consider a company that executes trades between buyers and sellers. The company has over 100 million historical trades within a collection, and almost all of those trades have a state of "COMPLETED". They are held in the database for compliance purposes.

A new feature requires a query that returns trades with an "IN PROGRESS" state. Some analysis of the data shows that, in general, there would typically be about 10,000 trades with an "IN PROGRESS" state at any time, and the rest are marked as "COMPLETED".

Implementing a partial index with a filter that excludes trades with a "COMPLETED" state reduces that index's memory footprint by over 99.9%.

That's an incredible saving on precious database resources, resulting in you getting more performance from your cluster without increasing your spending.

5. Look for opportunities to use bulk writes.

Bulk writes are the best way to optimise write performance within a database without sharding. Whilst sharding allows us to scale write performance within our application, it does come at a considerable cost. Finding opportunities to implement bulk writes within your application effectively defers the need to shard and offsets the additional associated costs for a time.

It's about getting as much out of your unsharded cluster for as long as possible.

6. Always, always, always protect your primary.

One of the most unfortunate things I see is that developers don't maximise the use of their entire cluster. A typical MongoDB replica set comprises a primary and two secondary nodes; more often than not, all queries, whether read or write, are directed to the primary node. Secondary nodes are simply treated as spares in case the primary unexpectedly dies.

The reason? Well, there are several, but these are the most likely ones;

Not implementing query targeting, however, is a lost opportunity that results in the premature need to scale database clusters, which translates directly into unnecessary additional operational costs.

The later query targeting is introduced into a system, the more difficult it will be to introduce. But there may be some low-hanging fruit, and iteration can get you close to a more balanced use of your cluster.

Strategies for mitigating the risk of reading stale data are critical. The following are some strategies that we prefer;

In summary, the focus must always be to reduce the load on the primary node as much as possible. This needs to be a deliberate focus and requires engineering effort.

MongoDB drivers implement connection pools, and managing those connection pools can potentially minimise server resources and maximise application performance. There isn't a one size fits all answer for this. It comes down to understanding your application and its access patterns.

Most drivers can set the minimum and the maximum pool size parameters, and both need consideration. Still, irrespective of where you land on those values, you will want to pre-connect the connection pool to the database before bringing an application into service.

8. Enable the "Require Indexes" flag on your dev clusters.

MongoDB Atlas provides a "Require Indexes for All Queries" flag in the cluster configuration. This is a great flag to set on development clusters as it highlights to developers where queries will perform collection scans and where indexes are required. One of the reasons this is a great feature is that development databases are usually orders of magnitude smaller than production workloads. As such, the impact of collection scans is often hidden during testing.

Suppose a development cluster has enough resources to load the entire development database into RAM (frequently true). In that case, you will probably never know that a collection scan is happening (as it's happening in RAM). Having the database throw an exception in that scenario prevents the downstream impact should the application be pushed to production.

I would not enable this flag on production clusters.

9. Use MongoDB Atlas Search - be the rockstar.

It's like Google on your database. Your users are going to love it, and they're going to love you for it. It takes a bit of work to implement, but it's well worth the effort.

10. Automate DevOps via the Atlas Administration API.

One of the lesser-known features of MongoDB Atlas is the <a href="https://www.mongodb.com/docs/atlas/reference/api-resources-spec/" target="_blank">Atlas Administration API</a>. The API is well worth a look and provides the ability to build complex DevOps automation into your CICD processes, as well as cluster deployment, security and scaling, to name a few of the capabilities.

You might feel that this seems to be quite a lot to consider, and you're right, but the undeniable reality is that building efficient, high-performance applications doesn't happen by accident and depends on an appropriate level of engineering effort. The good news is that with some careful planning, most of these tips can be implemented and delivered at a framework level.

When we built the <a href="/technology/">Cloudize API Framework</a>, we spent months implementing these and other techniques into the framework's core, and the return for our customers and ourselves have been outstanding. Developers no longer have to think about writing code to implement these techniques. A few simple configuration options in our designer are all that it takes, and our low-code technology takes care of the rest.

In this blog article, we'll discuss our top 10 tips for building high-performance MongoDB applications.

Our Top 10 Tips for building High-Performance MongoDB Applications

We're delighted to share that we have released Version 23.1 of the Cloudize API Framework today.

Version 23.1 builds upon the <a href="/technology/white-papers/cloudize-api-framework-v22-2-performance-report/">stellar performance reputation of Version 22.2</a> with the addition of field-level authorization for both read and write operations. This capability builds upon our Function Level Access Control (resource-level policies) and Object Level Access Control (record-level access control) capabilities with even finer-grained controls that define which fields within a resource are filterable and projectable to API consumers based on their security roles.

In addition to this, another feature that we are very excited about is the introduction of branch fragments within our design tooling. Branch fragments allow for the definition of types within API contracts that can accept one of many definitions, each with its own validation rules. This capability allows for complex data structures to be designed without the need to handcraft any code and takes our technology even further into the low-code space.

Code quality and simplicity remain amongst our highest priorities, with the framework now being covered by over 3400 unique automated  tests that validate every testable aspect of the framework. Overall automated test coverage remains close to 95%, and complexity remains extremely low, as seen in the code analysis report below.

In addition to the above software changes, Version 23.1 now deploys on Node 18 and Typescript 4.9.x. Our infrastructure deployment options have also been extended to allow container deployment on both AWS Fargate and EC2 Clusters through ECS. In both cases, blue/green deployment provides instant rollback capabilities.

Looking ahead, we expect that Version 23.2 will be released in the second half of the year and will include the upgrade to Typescript version 5, version 5 of the MongoDB database driver and version 3 of the AWS driver. In addition, we are starting work on support for container deployments on AWS Graviton (ARM64) processors (which deliver better performance at a ~20-30% cost reduction) and are hopeful to have an update on that topic soon.

In this blog article, we'll discuss the new features included in Version 23.1 of the Cloudize API Framework.

Cloudize API Framework Version 23.1 Release

Managing spend has become a high-priority focal area for almost all businesses within the current economic climate. One of the lesser-known features of the MongoDB Atlas platform is that you can scale your database infrastructure up and down through code by using the <a href="https://www.mongodb.com/docs/atlas/reference/api-resources-spec/" target="_blank">MongoDB Atlas Administration API.</a>

In this article, we'll take a look at how we can leverage that capability to optimize our database spend.

We've open-sourced our <a href="https://github.com/cloudize/mongodb-atlas-scheduled-scaling-agent" target="_blank">MongoDB Atlas Scheduled Scaling Agent</a> and will discuss how you can quickly and easily implement it to manage your clusters, but before we get into the technical how-to of the article, let's look at two financial strategies that the solution presents.

Many database workloads, especially those where human interaction (such as website or app engagement) drives load, have strongly cyclical load patterns. In these scenarios, there may be an opportunity to automate scaling a database cluster down during off-peak times and to bank the savings (~30% of spend).

An example of this strategy would be a business that implements an M40 cluster to meet its peak demand, which can be scaled down to an M30 during off-peak periods (due to reduced load).

Equally, given the same access patterns, a business could choose not to bank the savings but rather optimize their spend by scaling down a level during off-peak times when demand is low and repurposing those cost savings to finance scaling up an additional level during high-demand periods. Implementing this strategy delivers twice the database processing capacity during high-demand periods for about the same spend.

An example of this strategy would be a business that implements an M40 cluster (~$245 per week) and is comfortable with its overall spend. However, it identifies that the M40 instance is excessive during off-peak times yet marginal during high-load periods. In this case, scaling down to an M30 during off-peak periods (12 hours a day on weekdays and 24 hours a day on weekends) and utilizing those savings to finance a more powerful M50 during high-demand periods (for a new overall spend of ~$249 per week) effectively repurposes the excess off-peak capacity to create additional headroom for those peak/high-load periods with almost no extra cost.

Another option, when the working sets are large, is to scale down from the M-series instances to R-series instances (i.e. M40 to R40), which deliver an equivalent amount of RAM per instance class, but with half the CPU capacity.

Understanding your specific workload requirements and matching your scaling strategy to meet those requirements is essential and only something you can do. That said, the Scheduled Scaling Agent will execute your strategy quickly and easily without too much fuss.

The code below shows the main body of the <a href="https://github.com/cloudize/mongodb-atlas-scheduled-scaling-agent" target="_blank">MongoDB Atlas Scheduled Scaling Agent</a>. It's a simple application that performs scaling actions as defined by you, the developer, by using an internal cron and is easily deployed on a low-spec virtual machine or, better yet, within a container.

The first step to implementing the solution is to <a href="https://github.com/cloudize/mongodb-atlas-scheduled-scaling-agent" target="_blank">fork the repo</a>, as you will be modifying a few settings that govern when the application performs scale-ups and scale-downs and what instance classes to scale to.

A few settings will need to be overridden to get things working. We'll deal with them here.

The <a href="https://www.mongodb.com/docs/atlas/reference/api-resources-spec/" target="_blank">MongoDB Atlas Administration API.</a> utilizes API Keys for access control. Each key consists of a public key and a private key. We advise you to grant the minimum possible permissions to the API Keys that you generate (through the MongoDB Atlas Web Console) and that you restrict them to the IP blocks that represent your infrastructure (specifically where your Scheduled Scaling Agent will be running). The application expects your API Keys to be provided via the following two environment variables within the container or VM where the Scheduled Scaling Agent will run.

In addition to providing the API Keys, you will need to configure a few constant parameters related to your Atlas Cluster, as well as the scale-up and scale-down rules. We've tried to make them as simple and self-explanatory as possible. These specifically are the settings you should configure to match your environment:

The only thing left to do is to run some tests and monitor the console output of the application.

In this blog article, we'll discuss strategies for optimizing our database spend through scheduled scaling with a practical open-source example you can implement within your environment.

Optimizing database spend with scheduled cluster scaling

Towards the end of last year, we collaborated with a client to understand the performance capabilities of a standard implementation of the <a href="/technology/">Cloudize API Framework</a> serving data from a <a href="https://www.mongodb.com/" target="_blank">MongoDB</a> database.

Now, we all know that, in general, almost any problem within the tech space can be solved if you throw enough money at it.

That doesn't, however, represent the real world, where cost performance and value for money are critical factors in assessing a solution's viability. For that reason, we agreed to implement some budgetary constraints to the test. In doing so, we would not only be able to validate the solution's performance capabilities but its cost performance as well.

There are essentially two core operational cost categories to a solution such as this. The database and the compute environment.

For the database, we imposed a cost limitation of $10K per month, and for the entire compute environment, we set an overall budget limit of $1/million requests.

The next challenge was to define the details of the problem to be solved. We were specifically interested in measuring the read performance characteristics of the <a href="/technology/">Cloudize API Framework</a>, but we didn't want to sacrifice any of the standard bells and whistles that it offers out of the box (things like Authentication & Authorization, Object Level Access Management, Auditing, Telemetry, Error Logging & Service Accounting to name a few).

We created some data (100 million addresses, to be precise) and designed an API to securely serve the data to the consumer.

That's always the fun part. Cloudize has some internal tooling (which we call Tesseract), which allows us to visually design an API in next to no time. The cool thing about Tesseract is that it constantly produces a functional API as we iterate through the design. This makes the process extremely fast and, quite frankly, compelling. There is nothing like success to drive success.

Within two hours, the API was working as intended and deployed within AWS. For this project, we decided to deploy on Fargate, so we wouldn't have to worry about managing servers. AWS would automagically handle that for us.

The SDK (which Tesseract created for us) was published and pulled into a load-testing application. With a few more keystrokes, the app was simulating three thousand concurrent users accessing random resources from the API (using the code above).

The load-testing application was deployed into AWS (again, on Fargate), and the scene was set.

It was time to scale the database up for the test.

Now, we exclusively use <a href="https://www.mongodb.com/atlas" target="_blank">MongoDB Atlas</a> for our database deployments. Outsourcing the management of your database infrastructure to the company that created the database is a total no-brainer. (If you're not convinced and still want to roll your own, call me, and I'll tell you about how, ten years ago, we lost our entire business overnight because we couldn't get a multi-terabyte self-managed database back online).

One of the great things about the database budget constraint we set for the test was that it was reasonable.

We couldn't go berserk, but we still had a wide array of options available, and we could get creative in our solution architecture. We considered sharding, but in the end, given the read-heavy workload of the test, we decided that a single replica set, including some read-only secondary nodes, would do the job nicely (the <a href="/technology/">Cloudize API Framework</a> makes it really simple to automatically distribute read load evenly across your secondaries, of course, only if that's what you want to do).

The results were truly impressive. We ran some calibration tests, and from those, we determined how many load-testing applications we needed to have running simultaneously to produce the desired load. We scaled the client applications and watched as the API scaled up to meet the demand. Within a few minutes, the test was at full capacity, with over 17,500 requests per second being served by API (that's over 1 million requests per minute - not bad considering the budget constraints).

The database behind the solution cost $8,540 per month (although, in reality, we only ran it for a few hours), and the compute cost (including the load balancer, containers, networking and bandwidth) came in at $0.31 per million requests. [you could probably shave off another 25-30% if you run your containers on EC2]

Could we have pushed the solution even further? Absolutely - no doubt about it.

If you're interested in the nitty-gritty of the test, <a href="/technology/white-papers/cloudize-api-framework-v22-2-performance-report/">click here to read the complete whitepaper</a>.

In this blog article, we'll describe how we collaborated with a client to build an API backed by a MongoDB database to serve over a million requests per minute.

Building an API serving a million requests per minute in 2 hours

Well, it's official - we are now Cloudize.

The name change has been brewing in the background for some time, and it better reflects what we do - we cloudize your business ideas.

While we loved our old name ("API Games"), unfortunately, most of the folks we met at conferences and meetups automatically assumed that we were in the business of developing games. This created unnecessary confusion and made cut-through challenging to achieve.

The original intent of the "API Games" name was to communicate that our low-code technologies were so advanced that customers could literally "game out" the design and development of powerful APIs in near real-time, which meant cycle-time, and, therefore, risk, was radically reduced.

This outcome remains a core success criterion of our product, but equally so does getting cut through in our marketing efforts for the business. As a result, we started exploring the idea of renaming the business in late 2022 and settled on Cloudize Limited.

We're excited about the new company name and how the brand is developing, and we hope to get feedback from you, our customers, as to what you think of the new direction.

Well, it's official - we are now Cloudize. The name change has been brewing in the background for some time, and it better reflects what we do - we cloudize business ideas.

Blog Articles