Abstract
The goal of serverless architecture is to host single-purpose applications that scale on demand. For a brand technology company, which will be referred to as Company X, serverless architecture allowed for a new dynamic web publishing system to generate web pages much more efficiently than their existing system. Company X's core platform allows businesses to collect and organize their data. They have various products that leverage the data stored on the core platform, such as AI-powered search, SEO-ready web pages, listings, and data analytics. The web publishing and serving engineering team ensures that Company X's geographic servers host generated pages correctly. It was the team's task to design the dynamic publishing system’s architecture, build each of its components and test the system end-to-end to generate, store, and serve serverless function data.
The motivation for creating this new system was the many drawbacks in the existing system, which required inefficient workarounds to generate pages that supported dynamic components. First, the new system allows for third-party interaction with Company X's products. The old system required an in-house consulting team to build web pages for the client on the core platform. The new system, however, allows anyone to leverage Company X's products and platform to build a webpage, opening Company X to a whole new customer base. Second, the new system supports serverless functions. These functions are dynamic, stored on the cloud, and rendered server side, which provides a variety of functionalities not present in the existing system.
The new publishing system is currently in the testing stages and requires various features to be ready for client use. The current system only supports GET requests. POST request functionality is still required. A dedicated web interface would be necessary for users to create, update and monitor their plugins. Finally, although the engineering team thoroughly tested the functionality of the publishing system, they did not yet conduct a load test. The technical paper is an in-depth design document for the dynamic publishing system. It describes in detail the motivations for migrating from the existing system, the new system's architecture, and a description of each of its components, and the outcomes of migrating.
When Satoshi Nakamoto first proposed Bitcoin, he introduced it as a type of electronic cash that would simplify online transactions. His goal was to create a decentralized currency based on cryptographic proof that required no mediating institution, which he believed would interfere with a person's autonomy (Nakamoto, 2008). While this may have been the initial use of Bitcoin, its role has vastly changed since its inception in 2008. Bitcoin is currently too volatile to be considered a stable currency, aligning it closer to a traditional investment (Baur & Dimpfl, 2021). Despite this, it is still widely used, amassing an astonishing $8.2 trillion in transactions in 2022, which equates to roughly $260,000 per second (Luvaga, 2023).
The main factors influencing Bitcoin are those interacting with it, including actors such as currency users, investors, and regulators. The numerous actors participating in Bitcoin's network are responsible for its inability to replicate a traditional currency. Differing goals among the actors modified the Bitcoin network, transforming it into what it is today: a speculative asset. A decentralized cryptocurrency, as Nakamoto described it, is a truly valuable technology. Cryptocurrencies have evolved since Bitcoin’s inception. New protocols have made them more efficient, highly capable and have even stabilized their price. Determining why Bitcoin failed as a currency may pave the way for future developers to iterate on its design to build a successful digital currency. The STS paper analyzes why Bitcoin failed as a currency, taking into consideration its design features and the actors that participate in its network to determine why it transformed into a speculative asset.
