Numbers That Matter: December 2020

This month's collection of statistics from across the technology and research landscape shows just how far distributed systems, big data, and connected infrastructure have come — and where they're heading next.

Platform Growth and Usage

Adoption curves continue to steepen. TikTok reached 1 billion users in half the time it took YouTube, Instagram, or Facebook to hit that mark. Reddit reports 52 million daily users in October, a 44% year-over-year increase. Daily online grocery sales in the US jumped 110% in April 2020, with DoorDash leading and Uber Eats closing the gap.

Online shopping set records over Thanksgiving, pulling in $5.1 billion — up 21.5% from 2019, with 47% of sales coming through mobile devices.

Infrastructure and Performance

Several notable scalability milestones emerged. Pinterest's cache infrastructure now handles 150 million peak requests per second. Redis is the most-used database on AWS, deployed by 28% of 2,100 companies surveyed by Sumo Logic. Gartner projects that 75% of databases will be cloud-hosted by 2022.

Ruby 3.0 benchmarks show a 3x performance improvement over Ruby 2.0 — though Rails applications in practice see roughly double the throughput, since a significant portion of Rails execution time isn't spent in Ruby code itself.

A Costly Recursion

A cautionary infrastructure tale: one developer received a $72,000 Google Cloud bill after an infinite recursion in a web scraper consumed 116 billion Firebase reads and 16,000 hours of Cloud Run compute time. Firebase handled about one billion reads per minute throughout the incident, which raises questions about silently upgrading free plans to paid ones.

Compute and Networks

The Cerebras CS-1 chip now contains 1.2 trillion transistors and performed 200-times faster than a supercomputer when simulating combustion in a power plant. AI-controlled Loon balloons maintained station for 312 days in a row — a capability that could support fire-watching platforms.

US broadband speeds increased 91% year over year. When new subsea cables go live in 2023–2024, African GDP is projected to rise .42% to .58% within the first two to three years of operation.

Space, Physics, and Curiosities

Launch costs are falling dramatically. SpaceX's Starship is projected to deliver payloads to low Earth orbit at $50/kg, compared to $5,000/kg with a Saturn V, $2,800/kg with a Falcon 9, and $1,400/kg with Falcon Heavy. More than 1,200 asteroids larger than a meter have struck Earth since 1988 — only five were detected in advance, never with more than a day's notice.

Spotify paid $2.25 for a song streamed 125,000 times. A single red blood cell weighs approximately 27 picograms. Social media usage beyond 300 minutes per day made young adults 2.8x more likely to develop depression within six months. And the TinyML device market is expected to reach hundreds of billions of units within a few years.

Outages, Compliance, and the Cost of Scale

Two cloud incidents frame this week’s conversation. Google’s global outage lasted 50 minutes and touched all services requiring Google account authentication. The company’s postmortem blamed an automated quota management system that reduced capacity for its central identity system, which could then not verify user requests. AWS’s Kinesis outage had a wider blast radius, taking down IoT and CloudWatch, which left operators blind.

Commentators drew different lessons. One developer noted that hard dependencies fail differently from soft ones; AWS teams may err, but their processes let them learn. Another offered a sharp analogy for SLA credits after an outage: getting hosting credits for days of downtime is like a restaurant sending a $50 gift card to a customer who faced a six-figure hospital bill after food poisoning. A third pointed at product design, arguing that engineers who build gadgets that become bricks when a remote server is unreachable deserve more blame than the cloud provider.

Multi-region failover got its own skeptical take: it’s like a kitchen fire extinguisher — it may work in theory, but if you only test it when the fire starts, it won’t.

Scaling

The blunt version: “things scale linearly until they don’t.” A more precise version came from a commenter who argued that doing 100x the work requires more than 100x the servers — something between 107x and 110x, plus the overhead of coordination. Conversely, optimizing a request from 1.5 seconds to 15ms isn’t just a speedup; it’s like adding 99 servers to a cluster. One engineer’s first-hand data: moving from GCP’s Cloud Run, Cloud SQL, and Compute Engine to DigitalOcean’s managed Postgres and Kubernetes cut a monthly bill from over $100 to about $40.

For Moore’s Law, one analyst noted that even its proponents concede planar scaling has lost steam since 28nm. At 7nm and below, performance and power gains are just 10-20% per node, with engineering costs that can reach a few hundred million dollars. Chipmakers are turning to chiplets and multi-die packaging instead. On the storage side, hard disk vendors still ship the vast majority of bytes despite flash advances.

Architecture and Performance Debates

A classic argument resurfaced: threads vs. events. The source points to Ousterhout’s 1995 case against threads and Brewer’s 2003 rebuttal. One engineer had his own proof point for formal methods: using TLA+ to write a formal proof before coding a from-scratch service component. The resulting Java was almost “fill-in-the-blanks,” production never saw an incident, and the rollout finished in four months instead of six — including global shadow-mode monitoring.

On latency, one researcher claimed optimized Java runs about 20-30% slower than very optimized C. That’s “absolutely awesome” for single-digit-microsecond applications from a brokerage, but it requires abandoning most of the standard library: no interfaces, collections, exceptions, or free object allocation. Manage preallocated pools, or the garbage collector will ruin your worst-case timing.

DNS reliability, per Geoff Huston, breaks down by response size: unfragmented UDP beats TCP on both efficiency and reliability; TCP beats fragmented UDP; fragmentation is where protocols go to die. And on congestion control, Huston sees research interest in how rate-based and loss-based systems compete for network resources — fairness may need redefinition.

Cloud Strategy and Economics

Open source business models drew a dire verdict from Joe Morrison: venture-backed companies can’t responsibly give away the software at the core of their value proposition. “Cloud killed open core,” he wrote. At best, successful companies eventually face a choice between betraying early adopters and a drawn-out decline. Less dramatically, IBM’s handling of Red Hat signals the “good-ole’ days” are over, and users who aren’t paying should not expect much concern.

Vendor-shopping advice for the cloud era: Zoom picked AWS as preferred cloud provider, reportedly leaning on an Oracle bid and a PR commitment for a 30% discount.

AWS infrastructure itself shifted: Flickr moved the vast majority of its non-GPU compute to Graviton2, saving roughly 40% per service migration. Woodside Energy ran a million-vCPU workload across three AWS Regions, getting answers in two hours versus a typical multi-week run. And Cloudflare’s details vary, but the result is often framed as 150x faster. Capital One, meanwhile, became the first U.S. bank to abandon its last data center and run fully on cloud.

One engineer summarized the temptation: “use frameworks as much as possible, use managed services as much as possible.” A solo developer preferred VMs to containers for a decade-old product, using server-generated pages with PJAX-style updates — the operational burden of a JavaScript frontend doesn’t justify itself for two people. Another small team reported Cloud Functions, Pub/Sub, and Apache Beam process tens of millions of daily events, praising the speed of development, but conceded cold-start latency is real and “like any Google product [it] could be deprecated at any time.”

On Kubernetes, one voice warned it can be costly to run yourself and more so on a managed service. But once running, describing a service in YAML and watching it scale feels natural.

Bits and Bytes of Infrastructure

Physics appears in both radar and datalink design. Light travels almost 50% faster through air than glass, so hollow-core fiber gives high-frequency traders roughly a third less data transit time than standard fiber of the same length. Starlink’s satellites orbit at 550 km, where one-way light time is 1.8ms; a home-to-gaming-server round trip at those altitudes is under 8ms. The crew’s enthusiasm about space lasers is tempered: they enable serving users without terrestrial gateways, but cutting cost and scaling production of the lasers is still hard.

F-22s and F-35s can’t talk to each other directly because the IFDL and MADL datalinks speak different waveforms. Linking them with legacy Link 16 broadcasts would negate stealth, so an autonomous drone is being tested as a network bridge.

The long tail of commentary included a security warning from MIT: blockchain-based voting risks undetectable, nation-scale election failures, and is not the way to secure elections. Even the most storied of scaling lessons — the hard disk’s endurance — gets a nod: flash has made leaps, but the bulk of shipped bytes still spins at 7200rpm. In Japan, an estimated 33,000 firms have operated for over a century; how old is your infrastructure?

One-Person SaaS, One-Person Complexity

The operator of Panelbear documents the full stack behind a solo-run SaaS. The working principles: treat infrastructure as cattle, stick with boring technology, and keep everything defined as code. A migration from DigitalOcean to Linode (stability issues) and then to AWS (a better deal) was manageable because the infrastructure was already described via Terraform and Kubernetes manifests. The stack: Python/TypeScript, Django/React/NextJS/Celery/Bootstrap 4, ClickHouse/PostgreSQL/Redis/RDS, Terraform/Docker/K8s/GitHub Actions, AWS/Cloudflare/Let's Encrypt/Namecheap, Prometheus/Grafana/Sentry/Loki, Fastmail/Sendgrid, and GitHub/PyCharm/VS Code/Poetry/Yarn/Invoke.

Uber's Swift Rewrite: A Cautionary Tale

A former Uber engineer recounts what nearly became the company's biggest engineering disaster: rewriting the iOS app in Swift. The original Objective-C app was built for fewer than 10 iOS engineers but had grown to be worked on by hundreds. The client-heavy architecture was already fragile, requiring constant hot fixes and release burns. Swift scaled fine past 10 engineers, then the wheels came off: the compiler was far slower than Objective-C, build times ballooned, and typeahead/debugging stopped working entirely.

The app's complexity is immense—regional regulations, cash payments, airport-specific pickup rules—which feeds an enormous binary. One engineer built an annealing algorithm into the release build to reorder optimization passes, shaving 11 MB of machine code and buying development runway. In hindsight, those involved agree: a rewrite was necessary, but it should have happened in Objective-C. A simple build scalability test early on would have exposed Swift's fundamental problem. The Swift experience also slowed Uber's Kotlin migration; today Uber Android remains mostly Java.

Lessons from the Kinesis Outage

AWS published its summary of the Kinesis event in us-east-1. The proximate cause: newly added capacity pushed every server in the fleet past the OS-configured maximum thread count. Cache construction could not complete, front-end servers were left with useless shard-maps, and requests could not be routed to back-end clusters. Since Kinesis underpins other AWS services, the failure cascaded—impacting Cognito and others in what many view as a systemic, not random, failure.

Commentary from the community highlights the same lessons that recur after every major cloud incident. Multi-AZ does not protect against software/OS issues—only against physical infrastructure failure. The relevant pattern is cell-based architecture: break services into smaller independent cells within an AZ to limit blast radius, and combine that with workload partitioning so CloudWatch, Cognito, and customer workloads don't share cells. Code deployment should also be limited to a subset of cells at a time, and cells capped in size so behavior at scale is testable.

AWS engineers note that nearly all services are regional in scope and are themselves scaled cell-by-cell within a region. IAM and Route 53 are global exceptions, but they're eventually consistent with read replicas everywhere. The standard advice stands: run in multiple regions (active-active or pilot-light standby) because Availability Zones alone won't save you from regional service failures. Cognito, however, is region-specific with no active-active or standby mode possible—user accounts can't be synced or backed up with passwords across regions—leaving its users stuck in a single-region posture.

There's also the availability-versus-security dilemma: should Cognito keep serving requests when part of its identity layer depends on a failing service? Short-circuiting the Kinesis path might improve availability, but at what cost to security posture? One engineer's reminder for those evaluating the response: "respect what has gone before." Nobody sets out to build something crappy—systems are built against the known constraints of their time, and today's decisions will be refactored in 3–5 years, so document accordingly.

€5 Million in Donations with Cloudflare Workers

A charity telethon processed €5 million in donations within two hours, peaking at 151 donations per second, with over 4 million requests hitting Cloudflare Workers. The team chose Workers over AWS Lambda because code runs on Cloudflare's global edge in V8 isolates—no containers, no VMs, no cold starts. The results: 99% of requests used less than 6.6 ms of CPU time, staying flat through the peak, versus the 100s of ms they were accustomed to with Lambda.

The compute layer scaled without drama, but everything around it had to keep up. Stripe began returning rate-limit errors; a call to Stripe's account manager and CTO raised the limits 5x within 30 minutes. A single Worker served the static React front-end and handled a back-end route that created Stripe payment intents. Full-payment-journey tests ran via Cypress on every commit to main using GitHub Actions; warnings were logged to Sentry and Slack. Cross-browser testing through Browserstack caught no critical user-journey issues. The takeaway: edge serverless keeps latency flat under spike load because it eliminates cold starts.

Vogels on Architecting for Failure

A second ACM Queue conversation with Werner Vogels covers the hard-won lessons from Amazon's early days. Joining in 1998 meant a single US website selling books on a monolithic C app across five servers with Berkeley DBs and one relational database. A core tenet from the start: don't lock yourself into an architecture, because two or three orders of magnitude of scale forces a rethink.

Vogels offers "everything fails, all the time." Memory bit flips require CRC/checksums on individual data structures—even TCP can't be fully trusted. Rather than building one big platform (which forces you to ship technology designed five years prior), Amazon built tools with quick customer feedback cycles. Small, verifiable components are key: a 2,000-line algorithm can be formally verified; 50,000 lines cannot. Simple building blocks enable a culture of audits, TLA+ checks, and durability reviews for everything changed in S3.

One design regret: combining account and identity concepts. An account is something you bill; identity is how you build systems—they were wrongly conflated early on and were painful to separate. Request count and request handling costs were also unanticipated and only later added to S3's pricing. Amazon's engineering culture also shows in its priorities: a dedicated year on 99.9th-percentile performance worked, a year on removing single points of failure worked, but a year focused on efficiency failed completely—it isn't customer-facing. Weekly operational reviews with senior and junior engineers together provide perhaps the highest-value learning the company has.

Glommio: Thread-per-Core for Rust

DataDog introduces Glommio, a thread-per-core crate for Rust and Linux. Research shows this architecture can improve tail latencies by up to 71%. Each core runs exactly one pinned thread, so the OS scheduler has nothing to move and context switches never occur. The model requires sharding—each thread owns a subset of data—and its biggest payoff is that locks are never needed.

Pinterest's Cache Infrastructure at Scale

Pinterest's distributed cache fleet runs across thousands of EC2 instances, caching hundreds of terabytes served at over 150 million requests per second at peak. Every API request fans out into a tree of RPCs hitting dozens of services—core data queries, recommendation systems, spam detection. A universal routing abstraction gives applications a fault-tolerant, consistent view of data, and the server fleet scales independently of the application layer.

Memcached and mcrouter are the backbone. A single r5.2xlarge sustains over 100K requests per second and tens of thousands of concurrent TCP connections without tangible latency degradation. Memcached's extstore extends capacity from DRAM to local NVMe flash: ~55 GB on an r5.2xlarge becomes nearly 1.7 TB on an i3.2xlarge for a fraction of the cost—a major win for capacity-bound use cases like Visual Search despite orders-of-magnitude DRAM/SSD latency differences. Pinterest operates ~100 distinct clusters with varying tenancy, hardware, and routing policies, accepting a maintenance burden in exchange for performance isolation and per-workload tuning.

Diffusing Serverless in a Large Organization

Episode #76 of the CDK Patterns podcast explores how Liberty IT adopted a serverless-first mandate across thousands of engineers. A CIO mandate created top-down buy-in—everyone knew they'd eventually go serverless. Technical Architect Matt Coulter then had to make adoption attractive rather than coercive. His approach: a public external site documenting serverless architecture patterns, with validation from AWS Heroes and supporting articles. Community validation is a form of social proof; patterns create shared vocabulary and focus developers overwhelmed by AWS's breadth.

Inside Liberty, Well-Architected design reviews became a conversation mechanism: when a team wants to do X, you can suggest a vetted, coded, documented CDK pattern implementing X—reducing the barrier to the direction you want rather than forcing it. The AWS Well-Architected Framework and Serverless Lens provide an objective third-party structure for what constitutes good design. CDK constructs encapsulate best practices for reuse, Liberty maintains tailored versions of every pattern with an internal setup tool, and tests built into CDK drive standardization. The broader philosophy, per John Hagel: scale the edge as fast as possible; as the edge scales it pulls people and resources from the core until the edge becomes the new core.

Storage Engines Hit the CPU Wall

Vectorized's engineering blog argues that storage system bottlenecks have shifted. Software doesn't run on category theory—it runs on superscalar CPUs with wide multi-channel memory and NVMe SSDs that respond in tens to hundreds of microseconds. SSDs are 100-1000x faster than spinning disks and 10x cheaper than a decade ago; public-cloud networks went from 1Gbps to 100Gbps. The new bottleneck is the CPU and the threading model.

Redpanda, a Kafka-API-compatible system, uses a thread-per-core architecture with structured message passing between pinned threads. One pinned thread per core handles network polling, async I/O submission, event reaping, timers, and compute tasks. Nothing may block for more than 500 microseconds; blocking longer injects latency elsewhere and triggers the Seastar reactor to print a stack-trace warning. On an i3en.metal's 96 vCPUs, that means exploiting 3.1 GHz sustained clocks, 768 GiB of memory, and NVMe devices capable of 2 million random IOPS at 4 KB blocks.

Cloud Economics Are Ridiculous

Corey Quinn's podcast episode argues that feature velocity outweighs cost optimization for most businesses—it's easier to make more money than to cut costs. Companies actually care about predicting the bill (the 18–36 month financial model) more than minimizing it. Is a 20% month-over-month increase an aberration or the new normal? Your cloud bill tracks your engineer count more than your customer count.

Large customers sign multi-year contracts with committed spend, which ironically removes the cloud's famed flexibility: commit to EC2, and you can't shift spend to Lambda when it launches. Sixty percent of global AWS spend is still EC2, leaving a very long tail of services. Bills are ridiculously complex—nobody understands them intuitively, human and AI alike. One vendor's leverage disappears the moment you're single-cloud. When spending $500M/year you need a dedicated bill-analysis team; at $2,000/month it's not worth it. Effective analysis needs strategic visibility, accounting skill, and deep engineering knowledge—rare in one person.

Several practical nuggets: autoscaling often fails to scale back down, so costs persist as traffic falls; many workloads have a constant baseline rather than a day/night cycle; data egress remains the cloud's Achilles heel (why Zoom chose Oracle); you can't buy differentiated network performance tiers the way you can for storage or CPU; and every cloud provider negotiates—at $100M/year you can dictate terms. Some workloads belong on-prem (manufacturing proximity, existing datacenter revenue). The honest way to learn what a service costs is to use it, and if you get a surprise bill, calling your provider usually gets it reversed—once.

Kubernetes Isn't for Everyone

Kelsey Hightower's podcast appearance pushes back on Kubernetes hype. Millions still run the LAMP stack on ten servers, process millions of requests a day, and build viable businesses. At KubeCon, while everyone bragged about cluster size, a small cohort confessed they deploy to AppEngine and it "just works" for eight years. The end game for any platform: "I have this app, here's how I want it run." Kubernetes exists to stop everyone from gluing components together themselves—the datacenter becomes one computer and k8s is its operating system. Its trajectory mirrors Linux: destined to sit invisibly at the bottom of the stack, everywhere and unremarked.

The Case of the Extra 40 ms

A Netflix Partner Engineer investigates playback stutter on one set-top box. The A/V pipeline is identical across devices until the decoder buffer; moving data into it is a device-specific routine running in its own thread, keeping the buffer full by repeatedly requesting the next frame, then sleeping 15 ms before invoking the handler again. For 60fps content—a frame every 16.66 ms—a 15 ms check interval is just fast enough.

Tracing showed the stuttering device invoked its handler every 55 ms instead of 15—an extra 40 ms that guarantees underrun. The cause was a bug in Android itself: the thread that should have been created while the app was foreground was sometimes created in the background, and an extra timer value from that background state was retained when moving to the foreground. Playback stuttered only in that narrow race.

OkCupid Moves from REST to GraphQL

OkCupid's GraphQL API has been in production for 1.5 years; features stopped being added to the REST API over a year ago. The graph handles up to 170K requests per minute across 227 entities. The first draft took nearly twice the REST API's time—unacceptable. A shadow-request release let them triage performance issues without affecting real users. Their evolving conclusion: business logic belongs centralized in the back-end; the graph's role is to fetch, format, and present that data to clients.

BBC's Isomorphic React Migration

BBC World Service moved 31 million weekly readers across 41 discrete sites from a legacy PHP monolith to Simorgh, an open-source isomorphic React SPA. Lighthouse performance improved 224% (24 to 94), best practices 27% (79 to 100). Total requests dropped 85% (112 to 17); blocking JS requests went from 9 to zero; JS size dropped 61%; total page weight is 60% smaller; DOM Content Loaded is 0.4s (an 85% improvement); visually complete time is 1.8s (down 62% from 4.7s).

Making Secondary Storage Queries Fast

Honeycomb describes accelerating "secondary" storage queries with Lambda. Each ~1GB segment is processed by a Lambda function that pulls data from S3, reads needed bits, and computes a local query result. Thousands of concurrent Lambda jobs run while their own servers merge the serialized responses with primary-storage results. Lambda becomes a force multiplier: each CPU core oversees hundreds of others, then the resources vanish when the query ends. Querying lots of secondary data now takes barely longer than querying a little; large queries run up to ten times faster. A compression-friendly file layout allowed switching from gzip to LZ4, making reads roughly three times faster without sacrificing much compression.

Egnyte's 7x Search Improvement

Egnyte's Elasticsearch performance journey combined version upgrades with architectural changes. Upgrading to 7.x unlocked newer optimizations and tooling. Each cluster was divided into 4 smaller per-region clusters, also cutting full-cluster backup times. Large indices were split, and separate indices provisioned for the biggest customers. Analysis showed the first 50 KB of document content gave identical search quality, cutting data size 30%. Trigrams were dropped—exact and prefix matches sufficed—and the exact-term query proved redundant given analyzed match queries. Parent-child documents hurt both search time and disk usage and were abandoned. A staging index temporarily holds documents before updates, reducing deleted-document overhead. Data-node memory rose from 30 GB to 200 GB per node to keep more data cached, and all clusters moved to SSD. On larger datasets, updating documents by ID outperformed doing so by path.

Distributed Systems and Tooling Roundup

Open Source Projects and Libraries

A number of projects have recently caught our attention for their practical applications in distributed and scalable systems:

  • Wayeb (github.com/ElAlev/Wayeb): A Complex Event Processing and Forecasting (CEP/F) engine written in Scala. It leverages symbolic automata and Markov models for its processing logic.
  • com-diag-diminuto (github.com/coverclock/com-diag-diminuto): A C-based systems programming library for Linux/GNU environments.
  • Vision Space Tech (github.com/visionspacetec): An open-source on-board computer platform designed specifically for CubeSats.
  • BBC Simorgh (github.com/bbc/simorgh): The BBC’s open-source Single Page Application, designed for their World Service web presence.
  • Hyperdimensional Computing Collection (github.com/HyperdimensionalComputing/collection): A curated list of projects exploring hyperdimensional computing. The core idea is that computing with "hypervectors" — as suggested by brain function — offers a more general and scalable model than traditional numeric computation, with a well-defined set of arithmetic operations that enable fast, one-shot learning without backpropagation.
  • System Design Primer (github.com/donnemartin/system-design-primer): An organized repository of resources dedicated to helping engineers learn how to build systems at scale.
  • Radicle (radicle.xyz): A peer-to-peer stack for code collaboration that removes the need for trusted intermediaries. Built on Git’s peer-to-peer foundation, it aims to provide the functionality of centralized code "forges" while preserving the distributed nature of version control.

Network Infrastructure: SuperCell

On the hardware side, Facebook has published details on SuperCell, a large-area coverage solution that pairs towers up to 250 meters high with high-gain, narrow-sectored antennas. This configuration is designed to increase both mobile data coverage range and capacity. Field measurements indicate that a 36-sector SuperCell base station on a 250-meter tower can serve a geographic area up to 65 times larger than a standard three-sector rural macro station on a 30-meter tower in comparable topography.

Recent Research and Publications

Several papers and technical reports offer deep dives into current challenges and solutions across the distributed systems spectrum:

  • Protean: VM Allocation Service at Scale: A paper from Microsoft Azure describing the service that allocates Virtual Machines (VMs) to millions of servers. A single Protean instance handles an entire availability zone (10-100k machines), enabling seamless failover and scale-out.
  • High Availability in Cheap Distributed Key Value Storage: Explores using NVMM (Non-Volatile Main Memory) for a distributed key-value store. It addresses open questions about performance and write endurance as the technology makes its way into data centers.
  • EPIC: Every Packet Is Checked in the Data Plane of a Path-Aware Internet: Proposes a family of data-plane protocols that ensure increasing security properties by checking each packet at every hop. EPIC claims significantly lower communication overhead than comparable systems (e.g., OPT and ICING) and demonstrates the ability to saturate a 40 Gbps link on commodity hardware using only efficient symmetric cryptographic operations.
  • Building a Fault-Tolerant Quantum Computer Using Concatenated Cat Codes: Research suggests that a quantum computer built with around 1,000 superconducting circuit components could run circuits intractable for classical supercomputers. Scaling to 32,000 components would enable simulations of the Hubbard model beyond classical reach.
  • Pigasus: Achieving 100Gbps Intrusion Prevention on a Single Server: This paper reports that the Pigasus system can handle 100Gbps traffic using an average of 5 CPU cores with 1 FPGA, consuming 38x less power than a CPU-only approach.
  • Concurrent and Distributed Systems Course: A 16-lecture course from Cambridge University covering both concurrent and distributed systems topics.

The REST vs. GraphQL Debate Revisited

A recent controlled experiment comparing REST and GraphQL found that GraphQL requires less effort to implement remote service queries (median times of 9 vs. 6 minutes). The advantage grows as REST endpoints become more complex, and GraphQL outperformed REST even among experienced graduate students with prior REST experience but no prior GraphQL exposure.

This research has sparked a lively and opinionated discussion:

  • One perspective (tsimionescu) argues that REST moves the complexity to the server, providing well-defined and useful query results. GraphQL, by contrast, puts the onus on the client to know the data model and understand joins, blurring lines into business logic territory and potentially leading to N+1 query problems.
  • Another (jillesvangurp) counters that GraphQL liberates developers from designing "gazillions of custom REST endpoints," especially when the frontend is the sole customer of the API. They express fatigue with intense debate over situational rules like PUT vs. POST, suggesting that this level of precision is only critical for third-party SDKs.
  • Critics (Lt_Riza_Hawkeye) point out that GraphQL’s elegance at Facebook relies heavily on its bespoke infrastructure, where massive dedicated teams maintain the query logic against their centralized object stores. This tight coupling makes its value outside such an environment questionable.
  • Meanwhile, one practitioner (mirekrusin) shares a successful alternative: a trading system built on JSON-RPC over WebSockets, with TypeScript types and runtime type checks for boundary validation. They find it fast, safe, and easy to maintain across services.

For another engineering take on this, Netflix has published a follow-up post on scaling its API with GraphQL Federation.