<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>The Migration Line</title><description>Real engineering migrations, monitored like live systems.</description><link>https://migrations.sepurisaikrishna.com/</link><language>en-us</language><item><title>Airbnb: Ruby sitar-agent on a Sparkey datastore → Java sitar-agent on a WAL-mode SQLite datastore</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-ruby-sitar-agent-to-java-sidecar/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-ruby-sitar-agent-to-java-sidecar/</guid><description>Airbnb&apos;s config-delivery sidecar, sitar-agent, was fully rewritten from Ruby to Java in 2024 — and its local datastore moved off a Sparkey store that had to lock the whole file on every write.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>sidecar</category><category>java</category></item><item><title>Airbnb: StatsD + Veneur → OpenTelemetry + vmagent (Prometheus)</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-statsd-veneur-to-opentelemetry-vmagent/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-statsd-veneur-to-opentelemetry-vmagent/</guid><description>Airbnb migrated its high-volume metrics pipeline off StatsD and a proprietary Veneur fork onto OpenTelemetry and VictoriaMetrics&apos; vmagent, scaling to over 100 million samples per second while solving a subtle undercounting bug that Prometheus&apos;s counter model introduced along the way.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>infra</category><category>observability</category><category>opentelemetry</category><category>prometheus</category></item><item><title>Cloudflare: ClickHouse with exclusive-locked query planning → ClickHouse with shared-lock, cached-copy query planning</title><link>https://migrations.sepurisaikrishna.com/migrations/cloudflare-clickhouse-query-plan-contention/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/cloudflare-clickhouse-query-plan-contention/</guid><description>Cloudflare&apos;s billing jobs run on a petabyte-scale ClickHouse cluster. After a routine partitioning change, they started slowing down for no visible reason — I/O, memory, and rows scanned all looked clean. The real cause was a mutex.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>database</category><category>clickhouse</category><category>performance</category><category>debugging</category></item><item><title>Discord: Data center SFUs → Cloudflare edge voice (Rust)</title><link>https://migrations.sepurisaikrishna.com/migrations/discord-data-center-sfus-to-cloudflare-edge-voice/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/discord-data-center-sfus-to-cloudflare-edge-voice/</guid><description>Discord moved voice onto Cloudflare&apos;s 300+ city edge, then spent weeks hunting European ping spikes that turned out to start inside its own event loop.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>voice</category><category>edge</category><category>rust</category><category>networking</category></item><item><title>DoorDash: Fragmented, per-market onboarding APIs → Unified modular workflow platform (DxO)</title><link>https://migrations.sepurisaikrishna.com/migrations/doordash-fragmented-onboarding-apis-to-unified-workflow-platform/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/doordash-fragmented-onboarding-apis-to-unified-workflow-platform/</guid><description>DoorDash rebuilt Dasher onboarding — three coexisting API versions, hard-coded per-country logic, and status scattered across multiple tables — into a single configurable workflow platform, then migrated every market onto it starting with the US, with zero user-facing regressions in any launch.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>infra</category><category>architecture</category><category>workflow</category><category>backend</category></item><item><title>Etsy: In-house ORM sharding + index database → Vitess vindexes</title><link>https://migrations.sepurisaikrishna.com/migrations/etsy-custom-database-sharding-to-vitess/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/etsy-custom-database-sharding-to-vitess/</guid><description>Etsy&apos;s ~1,000-shard MySQL cluster routed every query through a single index database — a full-site outage waiting to happen. Five years later it runs on Vitess.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>database</category><category>vitess</category><category>mysql</category><category>sharding</category></item><item><title>Grab: Hive Parquet, managed through the Hive Metastore → Apache Iceberg, rolled out highest-value tables first</title><link>https://migrations.sepurisaikrishna.com/migrations/grab-hive-parquet-to-apache-iceberg/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/grab-hive-parquet-to-apache-iceberg/</guid><description>Grab&apos;s Hive Metastore had become a single point of failure whose query planning time scaled linearly with partition count, while some ML datasets fragmented into thousands of sub-1MB files per partition. Moving to Iceberg cut one navigation query from 70 seconds to 6 — but adopting a second table format meant Grab had to build its own way to hide that fact from everyone downstream.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>apache-iceberg</category><category>spark</category><category>data-lake</category><category>hive</category></item><item><title>Meta: Customer-owned data ingestion pipelines → A self-managed, hyperscale data warehouse ingestion service</title><link>https://migrations.sepurisaikrishna.com/migrations/meta-legacy-data-ingestion-to-modern-ingestion-systems/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/meta-legacy-data-ingestion-to-modern-ingestion-systems/</guid><description>Meta&apos;s data ingestion system scrapes several petabytes of social graph data out of MySQL every day. The legacy pipeline design worked at small scale and started to buckle as landing-time requirements got stricter — so Meta migrated tens of thousands of jobs to a new architecture without a cutover.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>data-infrastructure</category><category>cdc</category><category>mysql</category><category>data-warehouse</category></item><item><title>Netflix: Compute Managed Batch (CMB), a homegrown batch queueing system → Kueue, on Kubernetes-native Titus</title><link>https://migrations.sepurisaikrishna.com/migrations/netflix-homegrown-batch-queueing-to-kueue/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/netflix-homegrown-batch-queueing-to-kueue/</guid><description>Netflix built Compute Managed Batch in 2018 because nothing in the Kubernetes ecosystem did what it needed. Seven years later, the open-source Kueue project did all of that and the features CMB never shipped — so Netflix moved millions of batch jobs onto it in a four-week production migration.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>batch</category><category>scheduling</category></item><item><title>Shopify: React Native (Shop app) → Native Swift and Kotlin</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-shop-app-react-native-to-native-swift-kotlin/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-shop-app-react-native-to-native-swift-kotlin/</guid><description>Shopify rebuilt its Shop app from React Native into fully native Swift and Kotlin, using AI coding agents to go from proof of concept to a published app store release in 12 weeks — cutting Android cold-start time by half and Android crash-adjacent instability by roughly 10x.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>frontend</category><category>mobile</category><category>react-native</category><category>swift</category></item><item><title>Uber: HDFS with Kerberos-based security → Google Cloud Storage via Storage Access Service</title><link>https://migrations.sepurisaikrishna.com/migrations/uber-hdfs-kerberos-to-gcs-storage-access-service/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/uber-hdfs-kerberos-to-gcs-storage-access-service/</guid><description>Uber moved 160+ petabytes of its on-prem Hadoop data lake to Google Cloud Storage while keeping its existing Kerberos-based security model intact, building an intermediary token-exchange service to bridge HDFS authentication and GCS IAM without any of the 150,000+ existing access policies needing to change.</description><pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate><category>infra</category><category>security</category><category>cloud</category><category>kerberos</category></item><item><title>Airbnb: Gradle → Bazel</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-jvm-monorepo-build-tools-to-bazel/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-jvm-monorepo-build-tools-to-bazel/</guid><description>Airbnb&apos;s JVM monorepo held tens of millions of lines of Java, Kotlin, and Scala. Moving it off Gradle and onto Bazel took 4.5 years.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>infra</category><category>bazel</category><category>monorepo</category><category>build-systems</category></item><item><title>Airbnb: Mussel v1 (custom key-value store) → Mussel v2 (NewSQL backend on Kubernetes)</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-mussel-v1-to-mussel-v2-newsql/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-mussel-v1-to-mussel-v2-newsql/</guid><description>Airbnb replaced the storage backend of Mussel, its core key-value store for derived data, with a NewSQL backend on a Kubernetes-native control plane — migrating more than a petabyte across thousands of tables with zero downtime or data loss via a blue/green, dual-write rollout.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>database</category><category>kubernetes</category><category>infra</category><category>migration</category></item><item><title>Airbnb: Standalone, high-end sharded database servers → An open-source distributed SQL database spread across three Kubernetes clusters</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-single-instance-database-to-distributed-database-on-kubernetes/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-single-instance-database-to-distributed-database-on-kubernetes/</guid><description>Airbnb runs an open-source distributed SQL database across three independent Kubernetes clusters, one per AWS availability zone, so a bad deploy only ever costs a third of the fleet.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>database</category><category>kubernetes</category><category>high-availability</category><category>infra</category></item><item><title>Lyft: Android Java codebase → Kotlin</title><link>https://migrations.sepurisaikrishna.com/migrations/lyft-android-java-codebase-to-kotlin/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/lyft-android-java-codebase-to-kotlin/</guid><description>Lyft spent seven years converting its Android apps from Java to Kotlin, then added a CI lint check so no one could add Java back.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>language</category><category>kotlin</category><category>android</category><category>tooling</category></item><item><title>Lyft: Fully Kubernetes-based ML compute → AWS SageMaker (offline) + Kubernetes (serving) hybrid</title><link>https://migrations.sepurisaikrishna.com/migrations/lyft-lyftlearn-kubernetes-to-sagemaker-hybrid/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/lyft-lyftlearn-kubernetes-to-sagemaker-hybrid/</guid><description>Lyft moved LyftLearn&apos;s offline training and batch-processing workloads off a fully self-managed Kubernetes stack and onto AWS SageMaker, while deliberately keeping online model serving on Kubernetes — requiring zero changes to any team&apos;s actual ML code.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>infra</category><category>machine-learning</category><category>kubernetes</category><category>aws</category></item><item><title>Shopify: React Native Old Architecture → React Native New Architecture</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-react-native-old-architecture-to-react-native-new-architecture/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-react-native-old-architecture-to-react-native-new-architecture/</guid><description>Shopify moved Shopify Mobile and Point of Sale onto React Native&apos;s New Architecture while shipping weekly, and watched production reveal cracks its internal testing never did.</description><pubDate>Wed, 01 Jan 2025 00:00:00 GMT</pubDate><category>frontend</category><category>react-native</category><category>mobile</category><category>rollout</category></item><item><title>Agoda: A single GraphQL monolith serving 70 clients → Microservices routed through a Smart Orchestrator</title><link>https://migrations.sepurisaikrishna.com/migrations/agoda-graphql-monolith-to-microservices/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/agoda-graphql-monolith-to-microservices/</guid><description>Agoda&apos;s GraphQL API had backed every client app since 2016. To split it into microservices without breaking any of the 70 clients depending on it, they migrated the clients before they touched the backend.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>graphql</category><category>microservices</category><category>migration-strategy</category><category>infra</category></item><item><title>Airbnb: Enzyme → React Testing Library (RTL)</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-enzyme-to-rtl/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-enzyme-to-rtl/</guid><description>Airbnb used an LLM-driven pipeline to migrate 3.5K React test files from Enzyme to RTL in 6 weeks instead of an estimated 1.5 years.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>testing</category><category>react</category><category>llm</category><category>automation</category></item><item><title>Canva: Scheduled worker services on MySQL (OLTP) → ELT pipeline on an OLAP warehouse (Snowflake)</title><link>https://migrations.sepurisaikrishna.com/migrations/canva-scheduled-workers-to-elt-olap/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/canva-scheduled-workers-to-elt-olap/</guid><description>Canva counts billions of content usages a month to pay creators. Counting them one database round trip at a time on MySQL was O(N) and took over a day — so they moved the counting into an OLAP warehouse.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>database</category><category>olap</category><category>snowflake</category><category>elt</category></item><item><title>Didi: Elasticsearch, with a parallel HDFS write path → ClickHouse, split into dedicated Log and Trace clusters</title><link>https://migrations.sepurisaikrishna.com/migrations/didi-elasticsearch-to-clickhouse/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/didi-elasticsearch-to-clickhouse/</guid><description>Didi&apos;s logs lived in Elasticsearch, written twice — once to ES for search, once to HDFS for analysis — at petabyte scale. Moving both onto ClickHouse cut machine cost 30% and made queries 4 times faster.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>clickhouse</category><category>elasticsearch</category><category>observability</category><category>database</category></item><item><title>Discord: Local MacBook Dev → Cloud Dev Environments (Coder)</title><link>https://migrations.sepurisaikrishna.com/migrations/discord-macbooks-to-coder/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/discord-macbooks-to-coder/</guid><description>Discord moved backend development for its entire engineering org off local MacBooks and into Coder cloud dev environments — and Apple&apos;s M1 set the deadline.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>devex</category><category>tooling</category><category>cloud</category></item><item><title>Figma: AWS Elastic Container Service (ECS) → Kubernetes (EKS)</title><link>https://migrations.sepurisaikrishna.com/migrations/figma-aws-elastic-container-service-to-kubernetes/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/figma-aws-elastic-container-service-to-kubernetes/</guid><description>Figma&apos;s teams were burning engineering hours working around ECS, so the infrastructure team moved most core services to EKS in under 12 months by refusing to change anything else.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>containers</category><category>aws</category></item><item><title>GOV.UK Notify: PostgreSQL 11 on GOV.UK PaaS → RDS PostgreSQL 15 on AWS</title><link>https://migrations.sepurisaikrishna.com/migrations/gov-uk-postgresql-database-to-new-instance-11-seconds-downtime/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/gov-uk-postgresql-database-to-new-instance-11-seconds-downtime/</guid><description>GOV.UK Notify moved a 400GB, 1.3-billion-row PostgreSQL database off a retiring platform and onto its own AWS account — and cut over live traffic in 11 seconds.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>database</category><category>postgresql</category><category>aws-dms</category><category>public-sector</category></item><item><title>Grab: Wide-column database (Counter Service storage) → Aerospike</title><link>https://migrations.sepurisaikrishna.com/migrations/grab-counter-service-wide-column-to-aerospike/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/grab-counter-service-wide-column-to-aerospike/</guid><description>Grab&apos;s Counter Service served a billion requests a day off a wide-column store. Moving to Aerospike with a map-based schema cut disk from ~3 TB to ~1 TB per node and p99 read latency by roughly half.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>database</category><category>aerospike</category><category>storage</category><category>latency</category></item><item><title>Pinterest: HBase → TiDB, with other workloads split to Druid/StarRocks, Goku, and KVStore</title><link>https://migrations.sepurisaikrishna.com/migrations/pinterest-hbase-to-deprecation-decision/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/pinterest-hbase-to-deprecation-decision/</guid><description>At its peak, Pinterest ran roughly 50 HBase clusters on 9,000 EC2 instances holding over 6 petabytes of data. By the end of 2021, the company decided to deprecate it entirely, splitting its workloads across four successor systems.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>database</category><category>hbase</category><category>tidb</category><category>decision</category></item><item><title>Shopify: Static-analysis boundaries (Packwerk) → Running-code isolation</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-packwerk-static-analysis-to-running-code/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-packwerk-static-analysis-to-running-code/</guid><description>Four years after shipping Packwerk, Shopify hit the wall: a package with zero Packwerk violations still crashed when run in isolation. The retrospective is an honest accounting of what static analysis missed.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>modularity</category><category>rails</category><category>packwerk</category><category>retrospective</category></item><item><title>Trip.com: A single Elasticsearch logging platform → ClickHouse, on multiple Kubernetes-managed clusters</title><link>https://migrations.sepurisaikrishna.com/migrations/tripcom-elasticsearch-to-clickhouse/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/tripcom-elasticsearch-to-clickhouse/</guid><description>Trip.com&apos;s 2012 Elasticsearch logging platform hit a wall at 4PB — request rejections, out-of-memory queries, and daily hot-to-cold migrations that degraded the whole cluster. ClickHouse took it from there to 40PB+.</description><pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate><category>clickhouse</category><category>elasticsearch</category><category>observability</category><category>database</category></item><item><title>37signals: Amazon Web Services → Own hardware</title><link>https://migrations.sepurisaikrishna.com/migrations/37signals-aws-to-own-hardware/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/37signals-aws-to-own-hardware/</guid><description>After 15 years on the cloud, 37signals concluded the promised savings never came and the team never shrank — so they bought their own servers and left.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>cloud-exit</category><category>infrastructure</category><category>cost</category><category>repatriation</category></item><item><title>Canva: Single shared RDS instance → Separate service database via AWS DMS</title><link>https://migrations.sepurisaikrishna.com/migrations/canva-self-managed-database-to-aws-dms-migration/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/canva-self-managed-database-to-aws-dms-migration/</guid><description>Canva&apos;s Creators Monetization team had to split over 1 TB of royalty-tracking data off a shared RDS instance without dropping a single usage event — because every dropped row is a mispaid creator.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>database</category><category>aws-dms</category><category>rds</category><category>migration</category></item><item><title>Datadog: Clustered search-system storage → Husky (decoupled compute + object storage)</title><link>https://migrations.sepurisaikrishna.com/migrations/datadog-elasticsearch-to-husky-event-store/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/datadog-elasticsearch-to-husky-event-store/</guid><description>Datadog&apos;s event platform outgrew its clustered search-system storage. Husky is the third-generation rebuild — a columnar store that decouples compute from storage on commodity object storage — and this is the design that guarantees exactly-once ingestion into it.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>database</category><category>storage</category><category>kafka</category><category>multi-tenancy</category></item><item><title>Discord: Airflow → Dagster + dbt</title><link>https://migrations.sepurisaikrishna.com/migrations/discord-airflow-to-dagster-dbt/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/discord-airflow-to-dagster-dbt/</guid><description>Discord outgrew Derived, its five-year-old in-house orchestrator, and picked Dagster plus dbt against four hard criteria.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>data</category><category>orchestration</category><category>dagster</category><category>dbt</category></item><item><title>DoorDash: Single-writer PostgreSQL (store_items table) → CockroachDB</title><link>https://migrations.sepurisaikrishna.com/migrations/doordash-postgresql-fulfillment-to-cockroachdb/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/doordash-postgresql-fulfillment-to-cockroachdb/</guid><description>DoorDash&apos;s push into grocery and convenience multiplied menu items until a single-writer Postgres table hit its internal 500GB ceiling. They built a facade layer first, then swapped the store underneath it for CockroachDB.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>database</category><category>cockroachdb</category><category>postgresql</category><category>distributed-sql</category></item><item><title>Dropbox: Replication alone → Pocket Watch verification</title><link>https://migrations.sepurisaikrishna.com/migrations/dropbox-replication-alone-to-pocket-watch/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/dropbox-replication-alone-to-pocket-watch/</guid><description>Magic Pocket stores multiple exabytes across over half a million disks. Pocket Watch is the six-system verification layer that continuously proves the data is still there — and it runs more traffic than the customers do.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>storage</category><category>magic-pocket</category><category>durability</category><category>verification</category></item><item><title>GitHub: Subversion support (on a Git backend) → Git only</title><link>https://migrations.sepurisaikrishna.com/migrations/github-subversion-to-git-only/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/github-subversion-to-git-only/</guid><description>GitHub spent fourteen years hosting Subversion so people could leave Subversion. By the end, under 0.02% of requests used it — so on January 8, 2024, it turned the bridge off.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>git</category><category>subversion</category><category>deprecation</category><category>platform</category></item><item><title>Instacart: Fragmented per-team data tools, including at least a dozen Airflow instances → A unified stack — dbt plus one Airflow deployment on Snowflake (project Ground Truth)</title><link>https://migrations.sepurisaikrishna.com/migrations/instacart-fragmented-multi-team-data-to-unified-dbt-airflow-snowflake/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/instacart-fragmented-multi-team-data-to-unified-dbt-airflow-snowflake/</guid><description>Every engineering pillar at Instacart had its own data tools, its own event framework, and its own Airflow. Ground Truth collapsed them into one stack in six months.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>data</category><category>dbt</category><category>airflow</category><category>snowflake</category></item><item><title>Netflix: Eureka + Ribbon client-side load balancing → Envoy service mesh with on-demand cluster discovery</title><link>https://migrations.sepurisaikrishna.com/migrations/netflix-eureka-ribbon-to-envoy-service-mesh/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/netflix-eureka-ribbon-to-envoy-service-mesh/</guid><description>Netflix moved its decade-old Eureka-and-Ribbon IPC architecture onto an Envoy-based service mesh, co-developing a new Envoy feature with Kinvolk — On-Demand Cluster Discovery — specifically so services could migrate with zero configuration changes required.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>infra</category><category>envoy</category><category>service-mesh</category><category>cloud</category></item><item><title>Slack: Monolithic architecture → Cell-based architecture</title><link>https://migrations.sepurisaikrishna.com/migrations/slack-monolithic-architecture-to-cell-based-architecture/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/slack-monolithic-architecture-to-cell-based-architecture/</guid><description>One flaky network link inside a single availability zone took Slack down twice in a day, so Slack spent 18 months building a button that drains an AZ.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>infra</category><category>cloud</category><category>availability</category><category>envoy</category></item><item><title>Vercel: Go → Rust</title><link>https://migrations.sepurisaikrishna.com/migrations/vercel-turborepo-go-to-rust-how/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/vercel-turborepo-go-to-rust-how/</guid><description>Having decided to move Turborepo from Go to Rust, Vercel&apos;s team rejected a ground-up rewrite. Instead they ran both languages at once, porting piece by piece behind a Rust entry point they call the Rust-Go-Rust sandwich -- and hit a segfaulting Alpine Linux binary along the way.</description><pubDate>Sun, 01 Jan 2023 00:00:00 GMT</pubDate><category>language</category><category>rust</category><category>go</category><category>ffi</category></item><item><title>Airbnb: Legacy payments in the Rails monolith → Product-agnostic payment orchestration platform</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-legacy-payments-to-payment-orchestration/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-legacy-payments-to-payment-orchestration/</guid><description>Airbnb&apos;s payment logic was welded to stay reservations, so every new product — Experiences, Resolution Center — meant reimplementing payments. This is the rebuild into an idempotent, product-agnostic orchestration platform.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>payments</category><category>orchestration</category><category>idempotency</category><category>soa</category></item><item><title>Airbnb: Manually orchestrated EC2 instances → Dynamically autoscaled Kubernetes clusters</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-manual-ec2-scaling-to-dynamic-kubernetes/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-manual-ec2-scaling-to-dynamic-kubernetes/</guid><description>Airbnb moved nearly all online services from hand-scaled EC2 machines onto thousands of Kubernetes nodes across a hundred-plus clusters, then had to teach the autoscaler Airbnb-specific business logic to keep it efficient.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>autoscaling</category><category>cloud</category></item><item><title>Canva: Snapshot replication → CDC-based service-aligned data platform</title><link>https://migrations.sepurisaikrishna.com/migrations/canva-snapshot-replication-to-cdc-data-platform/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/canva-snapshot-replication-to-cdc-data-platform/</guid><description>Canva was taking a full snapshot of every service database every 24 hours to feed a 5-petabyte Snowflake warehouse. When a snapshot started taking longer than 24 hours to extract, the whole schedule fell apart.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>database</category><category>cdc</category><category>snowflake</category><category>data-platform</category></item><item><title>Cloudflare: Nginx (NGINX/OpenResty + Lua) → Pingora (Rust)</title><link>https://migrations.sepurisaikrishna.com/migrations/cloudflare-nginx-to-pingora/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/cloudflare-nginx-to-pingora/</guid><description>Cloudflare evaluated forking NGINX, adopting another proxy, or starting clean — and built Pingora in Rust, cutting CPU by 70% and memory by 67% at over a trillion requests a day.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>proxy</category><category>rust</category><category>infrastructure</category><category>performance</category></item><item><title>Confluent: Apache ZooKeeper (Kafka metadata) → KRaft (Kafka Raft)</title><link>https://migrations.sepurisaikrishna.com/migrations/confluent-apache-zookeeper-to-kraft/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/confluent-apache-zookeeper-to-kraft/</guid><description>Kafka kept its metadata in a second distributed system, and that second system capped how many partitions Kafka could hold. KIP-500 moves the metadata into Kafka itself.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>kafka</category><category>zookeeper</category><category>raft</category><category>distributed-systems</category></item><item><title>DoorDash: AWS SQS + Kinesis (data pipelines) → Apache Kafka + Apache Flink</title><link>https://migrations.sepurisaikrishna.com/migrations/doordash-aws-sqs-kinesis-to-apache-kafka-apache-flink/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/doordash-aws-sqs-kinesis-to-apache-kafka-apache-flink/</guid><description>Every one of DoorDash&apos;s data pipelines worked, yet data arrived late and cost too much. The culprit was the shape of the collection, not any single pipe.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>infra</category><category>kafka</category><category>flink</category><category>streaming</category></item><item><title>GitHub: Ruby pre-receive hooks (in the Rails monolith) → A dedicated Go service</title><link>https://migrations.sepurisaikrishna.com/migrations/github-ruby-hooks-to-go/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/github-ruby-hooks-to-go/</guid><description>Every git push to GitHub ran Ruby hooks that spent about 880 milliseconds loading dependencies before doing any work — so pushing nothing at all took over two seconds.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>go</category><category>ruby</category><category>performance</category><category>git</category></item><item><title>LinkedIn: Voldemort and proprietary derived-data stores → Venice</title><link>https://migrations.sepurisaikrishna.com/migrations/linkedin-custom-derived-data-stores-to-venice/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/linkedin-custom-derived-data-stores-to-venice/</guid><description>LinkedIn&apos;s batch and stream jobs needed somewhere fast to land online, and the answer was Voldemort Read-Only stores plus a scatter of proprietary systems. Venice replaced them with one platform, now open source.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>database</category><category>data-platform</category><category>streaming</category><category>open-source</category></item><item><title>LinkedIn: Kafka Mirror Maker (KMM) → Brooklin</title><link>https://migrations.sepurisaikrishna.com/migrations/linkedin-kafka-mirror-maker-to-brooklin/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/linkedin-kafka-mirror-maker-to-brooklin/</guid><description>LinkedIn left Kafka Mirror Maker for Brooklin in 2018 and got stability — but its mirroring pipelines still blew their latency SLAs, and the reason was hiding in how partitions were counted.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>infra</category><category>kafka</category><category>streaming</category><category>brooklin</category></item><item><title>Mozilla: google-breakpad (C++ minidump processor) → rust-minidump / minidump-stackwalk (Rust)</title><link>https://migrations.sepurisaikrishna.com/migrations/mozilla-cpp-minidump-processor-to-rust-minidump/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/mozilla-cpp-minidump-processor-to-rust-minidump/</guid><description>Mozilla spent about a year replacing google-breakpad&apos;s minidump processor with a pure-Rust rewrite, tested it against the old C++ system on real production crash reports, and shipped it — half the runtime, more reliable, and, by the article&apos;s own admission, still not done fighting the format&apos;s edge cases.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>rust</category><category>crash-reporting</category><category>testing</category><category>breakpad</category></item><item><title>Pinterest: HBase → TiDB</title><link>https://migrations.sepurisaikrishna.com/migrations/pinterest-hbase-to-tidb-zero-downtime/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/pinterest-hbase-to-tidb-zero-downtime/</guid><description>Pinterest moved a 4 TB HBase table serving 14,000 reads and 400 writes per second onto TiDB with no downtime, verifying 99.999% consistency between the two systems before finally deprecating the HBase table.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>database</category><category>hbase</category><category>tidb</category><category>migration</category></item><item><title>Pinterest: Pinball (in-house workflow system) → Spinner (Apache Airflow, custom branch)</title><link>https://migrations.sepurisaikrishna.com/migrations/pinterest-pinball-to-spinner-airflow/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/pinterest-pinball-to-spinner-airflow/</guid><description>Pinterest built a transparent migration layer that translated legacy Pinball workflow definitions into native Airflow DAGs on the fly, moving more than 3,000 workflows to its new Spinner platform with no required user code changes.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>infra</category><category>workflow</category><category>kubernetes</category><category>airflow</category></item><item><title>Twitter: On-prem HDFS (Hadoop) → Google Cloud / BigQuery</title><link>https://migrations.sepurisaikrishna.com/migrations/twitter-hdfs-to-google-cloud-bigquery/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/twitter-hdfs-to-google-cloud-bigquery/</guid><description>Team-by-team, Twitter&apos;s exabyte move to BigQuery crawled — two weeks per dataset and choking on a 77 Gbit/s proxy. An automated framework cut that to one hour.</description><pubDate>Sat, 01 Jan 2022 00:00:00 GMT</pubDate><category>cloud</category><category>bigquery</category><category>hadoop</category><category>data-platform</category></item><item><title>Airbnb: Zookeeper cluster (Kafka) → New Zookeeper cluster</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-zookeeper-cluster-to-new-zookeeper-cluster/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-zookeeper-cluster-to-new-zookeeper-cluster/</guid><description>Airbnb&apos;s biggest Kafka cluster stored its metadata in a shared Zookeeper ensemble that nobody owned, so the team moved it to a dedicated one with no downtime and no data loss.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>infra</category><category>kafka</category><category>zookeeper</category><category>migration</category></item><item><title>Box: Apache HBase (on-premises) → Google Cloud Bigtable</title><link>https://migrations.sepurisaikrishna.com/migrations/box-apache-hbase-to-google-cloud-bigtable/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/box-apache-hbase-to-google-cloud-bigtable/</guid><description>Box moved 600 TB of file metadata off three on-premises HBase clusters onto two Bigtable clusters with zero downtime, by writing to both databases synchronously until it trusted the new one.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>database</category><category>hbase</category><category>bigtable</category><category>gcp</category></item><item><title>Confluent: Separate ZooKeeper dependency → KRaft (Kafka built-in consensus)</title><link>https://migrations.sepurisaikrishna.com/migrations/confluent-separate-zookeeper-dependency-to-kraft/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/confluent-separate-zookeeper-dependency-to-kraft/</guid><description>Kafka kept its metadata in ZooKeeper, so every controller failover meant re-reading the whole cluster&apos;s metadata before it could act. Confluent moved that metadata into a Kafka log and replaced the single controller with a quorum.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>kafka</category><category>zookeeper</category><category>kraft</category><category>consensus</category></item><item><title>Dropbox: Python monolith (Metaserver) → Managed microservices platform (Atlas)</title><link>https://migrations.sepurisaikrishna.com/migrations/dropbox-python-monolith-to-managed-microservices-platform/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/dropbox-python-monolith-to-managed-microservices-platform/</guid><description>Dropbox tried breaking its 3-million-line Python monolith into services, decided most teams shouldn&apos;t run services at all, and built a managed platform instead.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>monolith</category><category>microservices</category><category>python</category><category>platform</category></item><item><title>Khan Academy: Python 2 → Go</title><link>https://migrations.sepurisaikrishna.com/migrations/khan-academy-python2-to-go/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/khan-academy-python2-to-go/</guid><description>How an end-of-life deadline turned into a full backend rewrite</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>language</category><category>backend</category></item><item><title>Khan Academy: Two forced migrations, Python 2 and App Engine → Go services + GraphQL, shipped one field at a time</title><link>https://migrations.sepurisaikrishna.com/migrations/khan-academy-technical-choices-behind-rewrite/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/khan-academy-technical-choices-behind-rewrite/</guid><description>Facing Python 2&apos;s end of life, Khan Academy didn&apos;t just port the language — they priced a full rewrite against the cheaper fix, chose the bigger bet, and then spent the project proving that a rewrite doesn&apos;t have to be &quot;big bang.&quot;</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>decision-record</category><category>go</category><category>graphql</category><category>migration-strategy</category></item><item><title>Spotify: Hadoop-based event delivery → Google Dataflow + a stateless receiver</title><link>https://migrations.sepurisaikrishna.com/migrations/spotify-hadoop-event-delivery-to-dataflow/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/spotify-hadoop-event-delivery-to-dataflow/</guid><description>Spotify rebuilt the pipeline that carries every event it collects — while it was carrying nearly 8 million events per second — and then spent the long tail waiting for 600+ legacy event types to catch up.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>data</category><category>streaming</category><category>dataflow</category><category>cloud</category></item><item><title>Zerodha: Per-system sync APIs → Kafka as the org-wide message bus</title><link>https://migrations.sepurisaikrishna.com/migrations/zerodha-per-service-apis-to-kafka-org-wide-bus/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/zerodha-per-service-apis-to-kafka-org-wide-bus/</guid><description>Dozens of Zerodha&apos;s internal systems stayed in sync by calling each other&apos;s APIs directly — a maze that grew for years. They cut the direct connections and let every system publish to, or read from, one shared Kafka bus instead.</description><pubDate>Fri, 01 Jan 2021 00:00:00 GMT</pubDate><category>kafka</category><category>event-driven</category><category>decoupling</category><category>infra</category></item><item><title>Airbnb: JavaScript → TypeScript</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-javascript-to-typescript/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-javascript-to-typescript/</guid><description>Airbnb converted a 6-million-line frontend monorepo to TypeScript by writing a tool that migrates a whole project in a day — and deliberately fills it with types that are wrong on purpose.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>typescript</category><category>javascript</category><category>codemod</category><category>frontend</category></item><item><title>Atlassian: Single-tenant Confluence → Stateless multi-tenant on AWS (Project Vertigo)</title><link>https://migrations.sepurisaikrishna.com/migrations/atlassian-single-tenant-to-multi-tenant-aws/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/atlassian-single-tenant-to-multi-tenant-aws/</guid><description>Confluence Cloud&apos;s real ceiling wasn&apos;t CPU or memory — it was database connections, and one busy tenant could exhaust them for everyone. Vertigo rebuilt the architecture around that fact.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>aws</category><category>multi-tenant</category><category>architecture</category><category>scaling</category></item><item><title>Coinbase: Polyrepo (many small repos) → Bazel monorepo</title><link>https://migrations.sepurisaikrishna.com/migrations/coinbase-multi-repo-to-bazel-monorepo/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/coinbase-multi-repo-to-bazel-monorepo/</guid><description>Coinbase had nearly a thousand services in separate repos, where a fix to a shared library could take months to roll out. So they bet on a Bazel monorepo.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>monorepo</category><category>bazel</category><category>build</category><category>developer-productivity</category></item><item><title>DoorDash: Python 2 monolith → Go microservices</title><link>https://migrations.sepurisaikrishna.com/migrations/doordash-python-2-monolith-to-go-microservices/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/doordash-python-2-monolith-to-go-microservices/</guid><description>Splitting the monolith bought DoorDash developer velocity and independent deploys — and a new class of failure where one slow database took the app down for three hours.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>infra</category><category>microservices</category><category>reliability</category><category>resilience</category></item><item><title>Duolingo: Java (Android app) → Kotlin</title><link>https://migrations.sepurisaikrishna.com/migrations/duolingo-java-to-kotlin-android/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/duolingo-java-to-kotlin-android/</guid><description>Duolingo&apos;s Android app spent its first five years as a Java codebase, then fully converted to Kotlin over two years — cutting converted files&apos; line counts by around 30% on average and flattening a previously 46% year-over-year codebase growth rate.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>language</category><category>mobile</category><category>android</category><category>kotlin</category></item><item><title>Etsy: 2000+ on-premises servers → Google Cloud</title><link>https://migrations.sepurisaikrishna.com/migrations/etsy-2000-premises-servers-to-google-cloud/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/etsy-2000-premises-servers-to-google-cloud/</guid><description>Etsy moved more than 5.5 petabytes off 2,000-plus on-premises servers to Google Cloud in two years, and got back 15% of its engineering headcount.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>cloud</category><category>gcp</category><category>infrastructure</category></item><item><title>GitHub: Ruby 2.6 → Ruby 2.7 (the step to Ruby 3)</title><link>https://migrations.sepurisaikrishna.com/migrations/github-ruby-2-6-to-ruby-2-7/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/github-ruby-2-6-to-ruby-2-7/</guid><description>GitHub fixed over 11,000 deprecation warnings across 400,000 lines of code to reach Ruby 2.7 — because 2.7 was the only door to Ruby 3.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>ruby</category><category>language</category><category>upgrade</category><category>deprecation</category></item><item><title>Lyft: Custom Express-based frontend stack → Next.js (100+ microservices)</title><link>https://migrations.sepurisaikrishna.com/migrations/lyft-custom-express-based-frontend-to-next-js/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/lyft-custom-express-based-frontend-to-next-js/</guid><description>Lyft&apos;s homegrown Express build system scaled to a hundred frontend microservices — and then upgrading it became a showstopper, so Lyft rebuilt the platform on Next.js.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>frontend</category><category>nextjs</category><category>express</category><category>platform</category></item><item><title>Shopify: 3,000-line God Object (Shop model) → Strangler-Fig-extracted domains</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-god-object-to-strangler-fig-pattern/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-god-object-to-strangler-fig-pattern/</guid><description>Shopify&apos;s Shop model had grown past 3,000 lines into a God Object. Instead of a risky big-bang rewrite, they grew a new system over the old one and let the legacy code get strangled away.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>refactoring</category><category>rails</category><category>legacy</category><category>patterns</category></item><item><title>Shopify: Native iOS + Android apps → React Native</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-native-ios-android-apps-to-react-native/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-native-ios-android-apps-to-react-native/</guid><description>After three app experiments showed 95-99% code sharing and a team that felt twice as productive, Shopify decided all new mobile apps would be built in React Native.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>mobile</category><category>react-native</category><category>ios</category><category>android</category></item><item><title>Yelp: Mesos (PaaSTA) / Flink on AWS EMR → Kubernetes (PaaSTA) + Flink operator</title><link>https://migrations.sepurisaikrishna.com/migrations/yelp-mesos-to-kubernetes-paasta-flink/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/yelp-mesos-to-kubernetes-paasta-flink/</guid><description>Yelp&apos;s PaaSTA platform moved from Apache Mesos to Kubernetes so it could run stateful workloads. Flink was the first big tenant — and a custom Kubernetes operator cut cluster spin-up from around 30 minutes to under 2.</description><pubDate>Wed, 01 Jan 2020 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>flink</category><category>streaming</category></item><item><title>Airbnb: Resque/Redis job queue → Dynein (SQS + DynamoDB)</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-resque-redis-job-queue-to-dynein/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-resque-redis-job-queue-to-dynein/</guid><description>Airbnb&apos;s centralized Resque cluster was at-most-once and bounded by a single Redis instance, so the team built Dynein — a delayed job queue on SQS with a scheduler on DynamoDB.</description><pubDate>Tue, 01 Jan 2019 00:00:00 GMT</pubDate><category>infra</category><category>queueing</category><category>dynamodb</category><category>sqs</category></item><item><title>Dropbox: Untyped Python → Static-typed Python (mypy)</title><link>https://migrations.sepurisaikrishna.com/migrations/dropbox-untyped-python-to-static-typed-python/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/dropbox-untyped-python-to-static-typed-python/</guid><description>Dropbox annotated roughly 4 million lines of Python with mypy, and had to build a daemon and a compiler to keep the type checker fast enough to use.</description><pubDate>Tue, 01 Jan 2019 00:00:00 GMT</pubDate><category>python</category><category>mypy</category><category>types</category><category>tooling</category></item><item><title>Figma: Delta sync (full document on every change) → Incremental sync</title><link>https://migrations.sepurisaikrishna.com/migrations/figma-delta-sync-to-incremental-sync/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/figma-delta-sync-to-incremental-sync/</guid><description>Figma studied operational transforms and CRDTs, then built a simpler centralized model that syncs one property at a time instead of shipping document state around.</description><pubDate>Tue, 01 Jan 2019 00:00:00 GMT</pubDate><category>collaboration</category><category>crdt</category><category>websockets</category><category>sync</category></item><item><title>Instagram: Manual code review and regex-based lint checks → LibCST-powered lint framework and Pyre-driven codemods</title><link>https://migrations.sepurisaikrishna.com/migrations/instagram-manual-code-review-to-static-analysis/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/instagram-manual-code-review-to-static-analysis/</guid><description>Instagram&apos;s Python server is several million lines, edited by hundreds of engineers shipping hundreds of commits a day. A single shared-state linter couldn&apos;t keep up, so they rebuilt static analysis as infrastructure.</description><pubDate>Tue, 01 Jan 2019 00:00:00 GMT</pubDate><category>python</category><category>static-analysis</category><category>tooling</category><category>developer-productivity</category></item><item><title>Shopify: Tax logic scattered across the monolith → A single tax component</title><link>https://migrations.sepurisaikrishna.com/migrations/shopify-scattered-tax-code-to-tax-component/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/shopify-scattered-tax-code-to-tax-component/</guid><description>Tax code at Shopify was spread across components that knew too much about how tax worked. A change in Checkout could silently break Cart.</description><pubDate>Tue, 01 Jan 2019 00:00:00 GMT</pubDate><category>infra</category><category>componentization</category><category>architecture</category><category>monolith</category></item><item><title>Cloudflare: Custom JavaScript Workers sandbox → V8 Isolates (worker runtime)</title><link>https://migrations.sepurisaikrishna.com/migrations/cloudflare-custom-javascript-workers-sandbox-to-v8-isolates/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/cloudflare-custom-javascript-workers-sandbox-to-v8-isolates/</guid><description>Cloudflare needed to run untrusted customer code in 155 data centers without containers, so it borrowed the isolation mechanism Chrome uses to keep browser tabs apart.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>cloud</category><category>serverless</category><category>v8</category><category>javascript</category></item><item><title>Cloudflare: PostgreSQL + Citus → ClickHouse</title><link>https://migrations.sepurisaikrishna.com/migrations/cloudflare-postgres-citus-to-clickhouse-analytics/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/cloudflare-postgres-citus-to-clickhouse-analytics/</guid><description>Cloudflare&apos;s HTTP analytics pipeline hit a wall at 15 queries per second on a Postgres/Citus cluster. They rebuilt it on ClickHouse, shut down 12 database nodes, and deleted tens of thousands of lines of Go, SQL, Bash and PHP.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>database</category><category>analytics</category><category>clickhouse</category><category>kafka</category></item><item><title>GitHub: Self-hosted GitHub Enterprise Server → GitHub Enterprise Cloud</title><link>https://migrations.sepurisaikrishna.com/migrations/github-self-hosted-github-enterprise-to-github-enterprise-cloud/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/github-self-hosted-github-enterprise-to-github-enterprise-cloud/</guid><description>Etsy stopped running its own GitHub Enterprise Server and moved repositories to GitHub Enterprise Cloud, trading infrastructure self-reliance for third-party service.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>cloud</category><category>developer-tools</category><category>ci-cd</category><category>github</category></item><item><title>Grab: Monolith, then inconsistent microservices → Grab-Kit (standardized Go microservices)</title><link>https://migrations.sepurisaikrishna.com/migrations/grab-monolith-to-grab-kit-microservices/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/grab-monolith-to-grab-kit-microservices/</guid><description>Grab broke up its monolith and got a new problem — every team building services their own way, with logs in different formats and alerts nobody set up. Grab-Kit made the right way the fastest way.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>microservices</category><category>go</category><category>platform</category><category>tooling</category></item><item><title>Grab: Single Redis node (auth tokens) → AWS ElastiCache Redis cluster</title><link>https://migrations.sepurisaikrishna.com/migrations/grab-single-redis-to-elasticache-cluster/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/grab-single-redis-to-elasticache-cluster/</guid><description>Grab&apos;s authentication tokens lived on one Redis node, and it was about two months from choking. Here&apos;s how they moved to a 9-node ElastiCache cluster with zero downtime and no invalidated tokens.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>database</category><category>redis</category><category>migration</category><category>zero-downtime</category></item><item><title>LinkedIn: Samza&apos;s low-level, callback-based API, where every job hand-built its own windows and joins → Samza 1.0 — a high-level API, Apache Beam portability, Samza SQL, and a standalone mode</title><link>https://migrations.sepurisaikrishna.com/migrations/linkedin-early-stream-processing-to-samza-1-0/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/linkedin-early-stream-processing-to-samza-1-0/</guid><description>Samza gave LinkedIn a stable, fast engine for stream processing since 2013, but building on it meant writing windows and joins by hand and wiring jobs together through raw Kafka topics. Samza 1.0 layered a high-level API, Beam portability, and a SQL interface on the same engine.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>streaming</category><category>infra</category><category>kafka</category><category>samza</category></item><item><title>Netflix: Manual region failover, provisioning capacity cold → Project Nimble, pre-warmed dark capacity</title><link>https://migrations.sepurisaikrishna.com/migrations/netflix-legacy-region-evacuation-to-project-nimble/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/netflix-legacy-region-evacuation-to-project-nimble/</guid><description>Failing traffic out of a bad AWS region used to take Netflix close to 50 minutes, mostly waiting for new instances to boot. Project Nimble keeps fully booted, invisible standby capacity running at all times, so a failover becomes flipping a switch instead of provisioning from zero.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>infra</category><category>aws</category><category>resilience</category><category>failover</category></item><item><title>Salesforce: Emulated queues on custom objects → Platform Events — a Kafka-inspired time-ordered event log</title><link>https://migrations.sepurisaikrishna.com/migrations/salesforce-custom-eventing-to-kafka-inspired-platform-events/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/salesforce-custom-eventing-to-kafka-inspired-platform-events/</guid><description>Without native eventing, Salesforce customers were emulating message queues with custom objects — fragile, slow, and billed as extra storage. No existing broker pattern could scale to hundreds of thousands of tenants, so Salesforce borrowed Kafka&apos;s log instead of a queue.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>kafka</category><category>event-driven</category><category>multitenancy</category><category>infra</category></item><item><title>Slack: A single JSON blob column for all workspace preferences → An entity-attribute-value preferences table</title><link>https://migrations.sepurisaikrishna.com/migrations/slack-column-per-preference-to-eav-model/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/slack-column-per-preference-to-eav-model/</guid><description>Slack&apos;s 165 workspace preferences all lived in one JSON blob column, north of 55 kB per workspace. Reading one setting meant paying for the whole blob — so Slack gave every preference its own row instead.</description><pubDate>Mon, 01 Jan 2018 00:00:00 GMT</pubDate><category>database</category><category>schema</category><category>eav</category><category>scalability</category></item><item><title>Airbnb: Mocha (test runner) → Jest</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-mocha-to-jest/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-mocha-to-jest/</guid><description>Airbnb&apos;s Mocha suite took 12+ minutes in CI, 45 minutes locally, and flaked on 12% of builds. Jest cut it to 4m30s and ~1% flake — once they found the 480ms hiding in their spec helper.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>frontend</category><category>testing</category><category>javascript</category><category>ci</category></item><item><title>Airbnb: Rails monolith → Service-oriented architecture (Thrift + Dropwizard)</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-rails-monolith-to-soa/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-rails-monolith-to-soa/</guid><description>Airbnb&apos;s Rails monolith had no strongly typed service contracts and shipped every payload as bulky JSON. This is how they standardized on Thrift IDLs and generated Java services so a new one could take production traffic in weeks.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>infra</category><category>soa</category><category>thrift</category><category>dropwizard</category></item><item><title>Airbnb: Ruby on Rails monolith → Client-rendered React SPA on a v2 API</title><link>https://migrations.sepurisaikrishna.com/migrations/airbnb-rails-pages-to-react-spa/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/airbnb-rails-pages-to-react-spa/</guid><description>Swapping one small template for a React component broke unrelated parts of Airbnb&apos;s search page — and even its API response. The hunt for why ended in a rearchitecture away from Rails-delivered pages.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>frontend</category><category>rails</category><category>react</category><category>architecture</category></item><item><title>Cloudflare: OpenSSL (patched) → BoringSSL</title><link>https://migrations.sepurisaikrishna.com/migrations/cloudflare-openssl-to-boringssl/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/cloudflare-openssl-to-boringssl/</guid><description>Cloudflare&apos;s edge ran a patched OpenSSL fork alongside a separate Go stack that existed only to handle TLS 1.3. It folded both into BoringSSL.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>tls</category><category>security</category><category>crypto</category><category>infra</category></item><item><title>Discord: MongoDB → Cassandra</title><link>https://migrations.sepurisaikrishna.com/migrations/discord-mongodb-to-cassandra/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/discord-mongodb-to-cassandra/</guid><description>How Discord rebuilt message storage before MongoDB&apos;s single replica set hit its limit</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>databases</category><category>scale</category></item><item><title>Dropbox: Go (performance-critical services) → Rust</title><link>https://migrations.sepurisaikrishna.com/migrations/dropbox-go-to-rust/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/dropbox-go-to-rust/</guid><description>Dropbox rewrote Magic Pocket&apos;s storage engine in Rust and it worked so well that almost nobody learned it — and that turned out to be the problem.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>language</category><category>rust</category><category>go</category><category>teams</category></item><item><title>GitHub: Bare-metal Unicorn servers → Kubernetes</title><link>https://migrations.sepurisaikrishna.com/migrations/github-bare-metal-to-kubernetes/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/github-bare-metal-to-kubernetes/</guid><description>For eight years GitHub&apos;s main Ruby app ran on Unicorn processes managed by God on Puppet-configured servers, deployed over SSH. This is how they moved github.com&apos;s web and API traffic onto Kubernetes.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>infra</category><category>kubernetes</category><category>containers</category><category>deployment</category></item><item><title>Meta (Facebook): InnoDB (MySQL storage engine) → MyRocks (RocksDB-backed)</title><link>https://migrations.sepurisaikrishna.com/migrations/meta-innodb-to-myrocks/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/meta-innodb-to-myrocks/</guid><description>UDB, the database behind Facebook&apos;s social graph, had run out of space rather than speed — so Meta swapped its storage engine and halved its storage usage.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>database</category><category>mysql</category><category>rocksdb</category><category>storage</category></item><item><title>Mozilla: Single-threaded C++ CSS engine (Gecko) → Quantum CSS / Stylo (Rust, parallel, ported from Servo)</title><link>https://migrations.sepurisaikrishna.com/migrations/mozilla-firefox-css-engine-to-servo-stylo/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/mozilla-firefox-css-engine-to-servo-stylo/</guid><description>Firefox&apos;s CSS engine matched selectors and computed styles for every DOM node on a single core. Quantum CSS, ported wholesale from Mozilla&apos;s experimental Servo browser, splits that work across every core on the machine — safely, because Rust can prove at compile time that there&apos;s no data race to find.</description><pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate><category>rust</category><category>css</category><category>parallelism</category><category>servo</category></item><item><title>Coinbase: Ad-hoc manual MongoDB migrations → An automated migration panel</title><link>https://migrations.sepurisaikrishna.com/migrations/coinbase-ad-hoc-mongodb-migrations-to-automated-migration-panel/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/coinbase-ad-hoc-mongodb-migrations-to-automated-migration-panel/</guid><description>A Coinbase MongoDB migration meant finding one of a handful of engineers with production access to hand-run a script over tens of millions of records.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>database</category><category>mongodb</category><category>migrations</category><category>tooling</category></item><item><title>Etsy: Sequential PHP API (logic built twice) → API-first v3 with cURL concurrency</title><link>https://migrations.sepurisaikrishna.com/migrations/etsy-sequential-php-api-to-concurrent-api-first/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/etsy-sequential-php-api-to-concurrent-api-first/</guid><description>Etsy built every feature twice — once for the website, once for the API — in a PHP world with no concurrency. So they rebuilt the API from scratch, and taught PHP to run requests in parallel.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>api</category><category>concurrency</category><category>php</category><category>architecture</category></item><item><title>LinkedIn: Bare open-source Kafka, with topic setup left to producers/consumers and everything else routed through Kafka SREs → A purpose-built ecosystem of tools around Kafka (Nuage, LiKafka, Gobblin, an audit trail, Burrow)</title><link>https://migrations.sepurisaikrishna.com/migrations/linkedin-manual-kafka-administration-to-self-service-ecosystem/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/linkedin-manual-kafka-administration-to-self-service-ecosystem/</guid><description>LinkedIn&apos;s Kafka already let any team create a topic and start producing to it. What wasn&apos;t self-service — custom configs, topic metadata, access control — funneled through Kafka SREs, so LinkedIn built an entire tooling layer to close that gap at 1,400-broker scale.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>infra</category><category>kafka</category><category>streaming</category><category>tooling</category></item><item><title>Meta (Facebook): The tracelet-based HHVM JIT compiler → A profile-guided, region-based HHVM JIT compiler</title><link>https://migrations.sepurisaikrishna.com/migrations/meta-hhvm-jit-compiler-redesign/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/meta-hhvm-jit-compiler-redesign/</guid><description>HHVM&apos;s original JIT compiled PHP and Hack one small, type-guessed fragment at a time, re-checking types at every boundary. A three-year profile-guided redesign cut CPU usage for running Facebook by about 15 percent.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>language</category><category>hhvm</category><category>compilers</category><category>performance</category></item><item><title>Mozilla: Hand-written C++ MP4 metadata parser → Rust media parser (mp4parse-rust)</title><link>https://migrations.sepurisaikrishna.com/migrations/mozilla-cpp-firefox-components-to-rust/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/mozilla-cpp-firefox-components-to-rust/</guid><description>Firefox 48 shipped Mozilla&apos;s first production Rust code: an MP4 metadata parser built by Ralph Giles and Matthew Gregan, replacing C++ on the exact code path that reads untrusted video files from strangers on the internet.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>rust</category><category>memory-safety</category><category>firefox</category><category>media-parsing</category></item><item><title>Netflix: Oracle billing database, in Netflix data center → AWS — Cassandra for subscriber data, MySQL for payments</title><link>https://migrations.sepurisaikrishna.com/migrations/netflix-oracle-billing-to-aws-cassandra-mysql/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/netflix-oracle-billing-to-aws-cassandra-mysql/</guid><description>On January 4, 2016, right before Netflix expanded into 130 new countries, its billing infrastructure went 100% AWS cloud-native — splitting one Oracle database into Cassandra for subscribers and MySQL for payments, because payment processing needed ACID transactions.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>billing</category><category>cassandra</category><category>mysql</category><category>aws</category></item><item><title>Netflix: Zuul 1, blocking one-thread-per-connection gateway → Zuul 2, asynchronous non-blocking gateway on Netty</title><link>https://migrations.sepurisaikrishna.com/migrations/netflix-zuul-blocking-io-to-zuul-2-async-nonblocking/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/netflix-zuul-blocking-io-to-zuul-2-async-nonblocking/</guid><description>Zuul is Netflix&apos;s front door for every user&apos;s traffic. The original ran one thread per connection; at 83 million members with multiple devices each, that thread cost was the whole problem.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>infra</category><category>gateway</category><category>netty</category><category>async</category></item><item><title>Uber: PostgreSQL → MySQL</title><link>https://migrations.sepurisaikrishna.com/migrations/uber-postgresql-to-mysql/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/uber-postgresql-to-mysql/</guid><description>Uber traced write amplification, verbose replication, a corruption bug and painful upgrades back to one Postgres design choice — indexes pointing at physical disk locations — and moved to MySQL/InnoDB.</description><pubDate>Fri, 01 Jan 2016 00:00:00 GMT</pubDate><category>database</category><category>postgres</category><category>mysql</category><category>replication</category></item><item><title>Meta (Facebook): A single memcached instance → A globally distributed, multi-region memcache layer</title><link>https://migrations.sepurisaikrishna.com/migrations/meta-single-memcache-to-scaled-memcache-clusters/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/meta-single-memcache-to-scaled-memcache-clusters/</guid><description>Mark Zuckerberg downloaded memcached and installed it on Facebook&apos;s Apache web servers in August 2005 to stop page loads from crawling. By 2013, that same lineage of cache served billions of requests per second.</description><pubDate>Tue, 01 Jan 2013 00:00:00 GMT</pubDate><category>database</category><category>caching</category><category>memcache</category><category>infra</category></item><item><title>Etsy: Solr HTTP replication → BitTorrent replication</title><link>https://migrations.sepurisaikrishna.com/migrations/etsy-solr-http-replication-to-bittorrent/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/etsy-solr-http-replication-to-bittorrent/</guid><description>Etsy&apos;s search index grew from 2 GB to over 28 GB, and Solr&apos;s HTTP replication couldn&apos;t feed the replicas fast enough. So they made the search servers seed to each other, like a torrent.</description><pubDate>Sun, 01 Jan 2012 00:00:00 GMT</pubDate><category>search</category><category>solr</category><category>bittorrent</category><category>infrastructure</category></item><item><title>Amazon: Obidos monolith → SOA (Service-Oriented Architecture)</title><link>https://migrations.sepurisaikrishna.com/migrations/amazon-obidos-monolith-to-soa/</link><guid isPermaLink="true">https://migrations.sepurisaikrishna.com/migrations/amazon-obidos-monolith-to-soa/</guid><description>By 2001 the Obidos monolith behind amazon.com had become a deployment bottleneck, and a famous internal mandate broke it into services owned by two-pizza teams.</description><pubDate>Tue, 01 Jan 2002 00:00:00 GMT</pubDate><category>architecture</category><category>microservices</category><category>monolith</category><category>soa</category></item></channel></rss>