# microservices architecture Microservices architecture is a software architecture style composed of small, autonomous, independently deployable services, each implementing a business capability and communicating through defined APIs. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How We Refresh Razorpay's Data Warehouse 10x Faster with Graphs and Indexes DevFeed: [How We Refresh Razorpay's Data Warehouse 10x Faster with Graphs and Indexes]() Original publisher: [Read original article]() Author: Amit Prabhu Published: 2026-07-14T14:06:16Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [data](), [airflow](), [Apache Spark](), [Amazon S3](), [Apache Iceberg](), [microservices architecture](), [parquet](), [Architecture & Design]() Tags: [airflow](), [analytics](), [apache-iceberg](), [architecture](), [batch](), [data](), [graphs](), [infrastructure](), [parquet](), [pipelines](), [razorpay](), [spark](), [trino](), [warehouse]() ### AI overview Razorpay describes its data warehouse refresh pipeline, which builds wide denormalized Facts by joining data from multiple microservices. The article covers the original Airflow- and Spark-based full-refresh process, the underlying lake formats and query layer, and the scaling challenges that led the team to reconsider refresh strategy, data layout, and high-cardinality dimensions. ### Source excerpt Contributors: Utkarsh Koppikar Rohan Background Razorpay provides the payment infrastructure for millions of merchants globally. Behind every payment, settlement, and refund is a microservices architecture where each service owns its own database. While this keeps services independent and scalable, it creates a challenge for stakeholders who need to see across those boundaries. The Data Platform team manages the infrastructure that bridges this gap. Transactional data flows into the lake via CDC pipelines, ingested onto S3 in Delta Lake, Apache Iceberg, or plain Parquet formats. On top of the lake, we build domain-specific warehouse tables -- wide, pre-joined tables that co-locate all the data a consumer needs, queryable via Trino. These power two use cases: Analytics (internal dashboards on Tableau and Superset) and Reporting (merchants and regulated entities who download structured data exports; Razorpay generates nearly a million such reports per month). The warehouse tables that power both use cases are called Facts. A Fact is a flat denormalised table on S3, produced by joining 10 to 30 microservice tables and materialising the result once. A settlement Fact, for example, merges payments, refunds, adjustments, and card details into a single wide row so that a dashboard or report reads from a single table instead of joining across services in real time. It is closer to a domain-specific materialised view than a classical data warehouse fact table. We maintain over 50 such Facts, and approximately 40% of all merchant reports are served directly from them. As data volumes and the number of entities per fact grew, the batch generation pipeline began to show its limits, prompting us to rethink the refresh strategy, the data layout, and how to handle high-cardinality dimensions. The rest of this post covers that journey. The Full Refresh Pipeline: Our Baseline and the Pain The original full-refresh pipeline was straightforward. Schedule: Airflow schedules Spark jobs o ## Strategies for Migrating from a Monolith to Microservices DevFeed: [Strategies for Migrating from a Monolith to Microservices]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-06-23T07:55:12Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [Architecture & Design](), [microservices architecture](), [migration](), [legacy systems](), [gateway]() Tags: [api-gateway](), [architecture](), [automated](), [big-bang](), [feature-flags](), [incremental](), [legacy-systems](), [microservices](), [migration](), [monolith](), [parallel](), [rewrite](), [strategies](), [testing]() ### AI overview This tutorial outlines patterns for gradually moving from a monolithic architecture to microservices. It describes the Strangler Fig Pattern, Parallel Run Pattern, and Collaborator Pattern, covering techniques such as API gateways, incremental migration, traffic splitting, feature flags, and automated comparison testing. ### Source excerpt Top Strategies ## Strategies for Moving from a Monolith to Microservices DevFeed: [Strategies for Moving from a Monolith to Microservices]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-05-26T07:58:51Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [microservices architecture](), [migration](), [legacy systems](), [proxy]() Tags: [architecture](), [big-bang](), [feature-flags](), [incremental](), [monolith]() ### AI overview This tutorial describes patterns for gradually moving from a monolithic architecture to microservices. It covers the Strangler Fig Pattern, Parallel Run Pattern, and Collaborator Pattern in the supplied text, emphasizing incremental migration, traffic splitting, behavior comparison, feature flags, and reduced rewrite risk. ### Source excerpt Strategies worth knowing ## Microservices Deep Dive: Architecting for Scalability and Resilience DevFeed: [Microservices Deep Dive: Architecting for Scalability and Resilience]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [microservices architecture](), [Scalability](), [Resilience](), [Architecture & Design](), [Domain-driven design (DDD)](), [distributed-systems](), [Deployment]() Tags: [architecture](), [ci-cd](), [cloud](), [complexity](), [deployments](), [devops](), [distributed-systems](), [domain-driven-design-ddd](), [incident-response](), [independent](), [isolation](), [layer](), [microservices](), [observability](), [resilience](), [scalability](), [services](), [system-design]() ### AI overview This article explains how microservices replace a tightly coupled monolith with independently deployable services aligned to business capabilities. It covers benefits such as independent scaling, fault isolation, team autonomy, and technology flexibility, while noting the added costs of communication, observability, operations, and data management. It recommends using microservices when domain complexity and scale justify the operational cost, organizing services around bounded contexts, and extracting one domain at a time. ### Source excerpt Microservices trade deployment simplicity for independent scaling, fault isolation, and team autonomy, and they only pay off once domain complexity and scale justify the operational cost. Align services to bounded contexts, give each its own data store, and extract one domain at a time rather than splitting by technical layer. ## Order Dispatch Systems at Scale DevFeed: [Order Dispatch Systems at Scale]() Original publisher: [Read original article]() Author: Guest User Published: 2025-07-28T01:53:56Z Content type: tutorial Language: en Sources: [Kogan.com]() Topics: [Amazon Simple Queue Service (SQS)](), [event driven](), [Scalability](), [Amazon Web Services](), [Microservices](), [microservices architecture](), [Latency]() Tags: [aws](), [concurrency](), [event](), [event-driven](), [latency](), [microservices-architecture](), [scale](), [sqs]() ### AI overview This tutorial compares vertical and horizontal scaling, pull-based queues using AWS Simple Queue Service, and event-driven architecture for order dispatch systems. It describes queue trade-offs and explains how event subscribers can process orders independently and scale separately. ### Source excerpt How to load-balance like a seasoned waiter Software systems often parallel the real world. Imagine running a busy restaurant, where customers line up to make orders whilst the kitchen prepares the meals. In the software world, your users are the customers, and your backend services are the kitchen. With more people online than ever before, that line might start to grow out the front door. The ability to scale is no longer optional, it is essential. Know Your Options Vertical Scaling - Scale Up Horizontal Scaling - Scale Out Expanding your restaurant by adding more tables or a larger kitchen. In software terms, this means scaling up your infrastructure. More powerful CPUs, larger memory, increased throughput etc. This is a relative quick fix, but comes with diminishing returns and limits on how big everything can get. Opening new restaurant locations to serve more customers simultaneously and distribute existing flows. In software terms, this means adding more API servers, more worker nodes or creating many database replicas. This approach is more flexible and scalable than vertical scaling in the long term. A Steppingstone - Queues Just like how customers queue for their order, we create a pull-based task queue for our order management system using AWS Simple Queue Service (SQS). Tasks get queued into the SQS, and a consumer service will continuously poll this queue to process the tasks. This gives a lot of control for the queue consumer to dictate the frequency of polling, which works well in systems that cannot handle high throughput or requires non-concurrency like the SAP ERP (more on that later). SQS also provides built-in dead-letter-queues, retry policies, at least once delivery guarantee and scales automatically. Vertical scaling involves sizing up the compute power of the consumer (CPU, RAM etc). Horizontal scaling involves spinning up more consumers of the SQS. However, queues have limitations: Latency between order arrival and processing. Inefficient poll ## Microauthorization: Why Microservices can be Great for Security Hygiene DevFeed: [Microauthorization: Why Microservices can be Great for Security Hygiene]() Original publisher: [Read original article]() Published: 2025-05-08T00:00:00Z Content type: opinion Language: en Sources: [Chainguard: Unchained]() Topics: [Architecture & Design](), [microservices architecture](), [Security](), [Authorization](), [IAM]() Tags: [architecture](), [authorization](), [container-security](), [iam](), [least-privilege](), [microauthorization](), [microservices](), [remote-code-execution](), [security]() ### AI overview The article argues that decomposing monolithic applications into microservices can improve security hygiene by isolating processes and assigning each service a distinct identity with narrower IAM capabilities. It explains that service-to-service authorization can limit the blast radius of a breach, although attackers may still need to move laterally across services. ### Source excerpt Microservices can enable you to easily independently roll out services, but they can also provide security benefits. Learn more with Chainguard CTO Matt Moore. ## Architectural Design for a Ride App such as OLA, UBER, RAPIDO DevFeed: [Architectural Design for a Ride App such as OLA, UBER, RAPIDO]() Original publisher: [Read original article]() Author: ratneshmaurya2311@gmail.com (Ratnesh Maurya) Published: 2024-07-30T00:00:00Z Content type: article Language: en Sources: [Ratn Labs]() Topics: [microservices architecture](), [Architecture & Design](), [gRPC](), [App]() Tags: [architecture](), [backend](), [microservices](), [microservices-architecture](), [queues](), [rest](), [software-architecture](), [system-design](), [system-design-backend](), [tracking](), [vs]() ### AI overview An overview of architectural design for a ride-sharing app, covering microservice boundaries, REST, gRPC, message queues, geolocation tracking, and the trade-offs between starting with a monolith and adopting microservices. ### Source excerpt Microservices architecture for ride-sharing: service boundaries, REST vs gRPC vs message queues, geo-location tracking, and trade-offs between monolith-first and microservices. ## To choreograph or orchestrate your saga, that is the question DevFeed: [To choreograph or orchestrate your saga, that is the question]() Original publisher: [Read original article]() Author: Emily Fortuna Published: 2023-07-13T15:30:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [distributed-systems](), [microservices architecture](), [Orchestration](), [Architecture & Design](), [business logic]() Tags: [architecture](), [backend](), [debug](), [decoupling](), [distributed-systems](), [how-to](), [microservices](), [microservices-architecture](), [monolith](), [orchestration](), [ordering]() ### AI overview This article explains the saga pattern for tasks that span microservice boundaries and compares choreography with orchestration. It describes how choreography uses message passing and local service knowledge, while distributed ordering requirements can make control flow harder to understand and debug. ### Source excerpt An explanation of orchestration and choreography of microservices, and how Temporal works under the hood. Find out how and why. ## Imperfect #14: How to map dependencies DevFeed: [Imperfect #14: How to map dependencies]() Original publisher: [Read original article]() Author: Pedro Gil Carvalho Published: 2023-07-07T13:33:59Z Content type: tutorial Language: en Sources: [Pedro Gil Carvalho]() Topics: [Architecture & Design](), [microservices architecture](), [Microservice](), [interfaces](), [API](), [Database]() Tags: [api](), [architecture](), [awareness](), [changes](), [database](), [dependencies](), [distributed](), [issue-tracker](), [map](), [microservices](), [microservices-architecture](), [monitor](), [monolith](), [pair-programming]() ### AI overview The article explains how to map service dependencies to help identify and avoid distributed monoliths. It recommends team-by-team architecture reviews, collaboratively maintained diagrams, monitoring connected interfaces, and tracking dependencies in a simple spreadsheet. ### Source excerpt Avoiding the distributed monolith antipattern requires great situational awareness. Today we go over what that means, how architecture reviews can help, and one simple way to anticipate dependencies. ## Imperfect #13: Killing the Distributed Monolith DevFeed: [Imperfect #13: Killing the Distributed Monolith]() Original publisher: [Read original article]() Author: Pedro Gil Carvalho Published: 2023-06-30T09:03:26Z Content type: opinion Language: en Sources: [Pedro Gil Carvalho]() Topics: [Architecture & Design](), [microservices architecture](), [Microservices]() Tags: [architecture](), [distributed](), [microservices](), [microservices-architecture](), [monolith]() ### AI overview The article argues that a distributed monolith can emerge when microservices teams develop thick networks of dependencies. Using a retailer settings-page example, it describes how ownership boundaries, cross-team requests, context switching, and coordination delays can slow delivery and create defects. It presents the problem as both organizational and technical, with healthier boundaries as the proposed direction. ### Source excerpt Going faster through healthier boundaries ## Schema Services: Transitioning Towards a Federated Architecture DevFeed: [Schema Services: Transitioning Towards a Federated Architecture]() Original publisher: [Read original article]() Author: Andy Roberts Published: 2020-11-04T15:09:30Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Architecture & Design](), [microservices architecture](), [Microservices]() Tags: [apollo-federation](), [architecture](), [backend](), [cloud](), [graphql](), [microservices-architecture](), [rest](), [services]() ### AI overview This article introduces schema services as a transitionary architecture for organizations moving toward a federated GraphQL architecture. It discusses how schema services can help bridge legacy and modern services, mixed protocols, data-centric APIs, and GraphQL skills gaps during an Apollo Federation adoption. ### Source excerpt The reality for most large organizations adopting Federation is that the architecture sitting behind it is... messy. In this article, I will introduce the concept of schema services and demonstrate how they can provide an easier transition towards a federated architecture. From a jumble of modern and legacy services, different tech stacks, data sources, platforms, etc. most enterprise architecture diagrams look more like a grab bag of tech from the last couple of decades than anything else. ## The Road to an Envoy Service Mesh DevFeed: [The Road to an Envoy Service Mesh]() Original publisher: [Read original article]() Author: Snow Pettersen Published: 2019-03-29T15:36:51Z Content type: article Language: en Sources: [Square Corner Blog - Medium]() Topics: [microservices architecture](), [Architecture & Design](), [interoperability](), [Remote Procedure Call (RPC)](), [Go Language](), [Java](), [Ruby](), [Ruby on Rails](), [gRPC](), [Code]() Tags: [architecture](), [automatic](), [discovery](), [engineering](), [envoy-proxy](), [failover](), [go](), [http](), [interoperability](), [java](), [microservices](), [microservices-architecture](), [routing](), [rpc](), [ruby](), [service-mesh]() ### AI overview Square describes its evolution from a Ruby on Rails monolith to a microservices architecture and explains the interoperability challenges created by its Java, Ruby, and Go stack. The article outlines its Protobuf-based Sake RPC framework, its routing, failover, traffic-shaping, and service-discovery features, and Square's migration toward a full service mesh. ### Source excerpt Heads up, we've moved! If you'd like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog At Square we've been running a microservices architecture for years, primarily using three different languages: Java, Ruby and Go. Running such a diverse stack can make interoperability between the different languages/frameworks challenging, and in this post I'll talk about how Square has handled this in the past and where we're at today -- actively migrating towards a full service mesh. The Old World Square started off, like many other companies, just running one large monolith. For Square this was a big Ruby on Rails service, that handled everything that Square did. A monolith makes service to service communication completely unnecessary: everything runs in the same code base on a single database, so everything can be implemented without making any outbound network calls (except to third parties outside of Square). After a while, Square decided to move more towards a service oriented architecture to reduce the reliance on a single, large application. To do this Square decided to build their own Protobuf based RPC framework, inspired by Google's Stubby. This was years before gRPC was created, so there weren't any open source options at the time. This RPC framework, called Sake, was implemented for Java and Go as these were the languages used for higher availability services, while regular REST HTTP was used between services that didn't understand Sake. (Incidentally, Sake became a part of gRPC's DNA) Over time this framework became fairly sophisticated, with many features not generally available: Smart retries with automatic failover Prioritized routing based on upstream health Traffic shaping and service discovery This ended up working well, but relied on fat client/server libraries, so extending support to other languages was hard. Attempts were made to bring feature parity between languages i ## Microservices and the monolith DevFeed: [Microservices and the monolith]() Original publisher: [Read original article]() Published: 2016-08-26T00:00:00Z Content type: opinion Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Architecture & Design](), [Microservice](), [microservices architecture](), [HTTP](), [Prometheus](), [Docker](), [Kubernetes](), [Finagle](), [telemetry](), [Testing]() Tags: [architecture](), [docker](), [finagle](), [http](), [kubernetes](), [microservices](), [microservices-architecture](), [monolithic-architecture](), [prometheus](), [telemetry](), [testing]() ### AI overview SoundCloud reviews its migration from a monolithic architecture to microservices and evaluates the strategy needed to decommission the monolith. The article reports that internal tools and libraries improved service creation and engineering productivity, while extraction projects remained difficult because they took months and depended on multiple teams. ### Source excerpt In a previous series of blog posts, we covered our decision to move away from a monolithic architecture, replacing it with microservices, interacting synchronously with each other over HTTP, and asynchronously using events. In this post, we review our progress toward this goal, and talk about the conditions and strategy required to decommission our monolith. ## Finn.no's architecture summit focused on breaking up its iAD monolith into microservices DevFeed: [Finn.no's architecture summit focused on breaking up its iAD monolith into microservices]() Original publisher: [Read original article]() Author: Audun Fauchald Strand Published: 2015-02-10T11:00:00Z Content type: article Language: en Sources: [Finn.no]() Topics: [microservices architecture](), [Architecture & Design](), [Domain-driven design (DDD)](), [event driven](), [Node.js](), [RxJava](), [reactive](), [real-time](), [legacy]() Tags: [architecture](), [architectures](), [development](), [domain-driven-design](), [event-driven](), [legacy](), [microservices](), [microservices-architecture](), [node-js](), [reactive](), [real-time](), [rxjava]() ### AI overview Finn.no organized a two-day architecture summit to coordinate its development teams around a microservices architecture after breaking up the iAD monolith. The program covered domain-driven design, event-driven architecture, CQRS, service properties, and implementation examples using Node.js, RxJava, and Reactive Streams. ### Source excerpt After working several years with (successfully) breaking up the legacy monolith, called iAD, Finn.no wanted to add structure to this process, and make sure that all 20 development teams work towards the same target. The target is a microservices architecture with small-ish autonomous services, owning their own data. With that in mind we arranged our own two-day architecture summit for all Lead Developers, with a combination of external and internal presenters. The focus was on microservices, domain driven design, event driven architectures and modern programming techniques. We started off the first day with a long session. Finn.no's Chief Enterprise Architect Sebastian Verheughe wanted to communicate his vision. This included topics such as strategic domain-driven-design, data-highways, and how to use event-driven architecture to further decouple our services. This theme continued, with the first external presenter. Jan Ove Skogheim from Particular Software talked about his experiences from Rikstoto, and how they had broken up a monolith into multiple small services. He also talked about the composite-UI pattern. After lunch we continued with a presentation by Karsten Mevassvik from finn.no, of the most important properties for a finn.no microservice. These include: Is RESTful Owns its own data-store Team ownership Consumer Driven The first day of the summit was concluded with a presentation of the CQRS architectural pattern. This presentation was held by Idar Borlaug and Andreas Berre from WebStep. They showed all the central concepts in CQRS, such as commands, event-stores, aggregates, sagas using very good examples to illustrate their concepts. The second day of the summit started off with some hardcore programming. The frameworks of choice was node.js and RxJava. Christopher Kolstad started with an example of how a microservice could be implemented using Reactive Streams and RxJava. After that Phillip Johnsen presented a case using node.js in a real time context