# Remote Procedure Call (RPC) Remote procedure call (RPC) is a client-server communication model in which a caller sends procedure parameters to a server and receives procedure results in a reply. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Bringing QUIC to Seastar DevFeed: [Bringing QUIC to Seastar]() Original publisher: [Read original article]() Author: Cynthia Dunlop Published: 2026-09-14T13:02:07Z Content type: article Language: en Sources: [ScyllaDB]() Topics: [Seastar](), [networking](), [Remote Procedure Call (RPC)](), [C++](), [Latency](), [Protocol (disambiguation)]() Tags: [benchmarks](), [c-plus-plus](), [collaboration](), [engineering](), [latency](), [network](), [networking](), [rpc](), [scylladb](), [seastar](), [udp]() ### AI overview This article describes a University of Warsaw student project conducted with ScyllaDB to implement a QUIC transport for Seastar using the sans-I/O ngtcp2 library. It also adapts Seastar's RPC layer to operate over QUIC and reports benchmark results showing predictable overhead on a lossless loopback and benefits when packets are dropped. ### Source excerpt We built a QUIC transport for Seastar on top of ngtcp2's sans-I/O state machine, then adapted RPC to it twice: 1) as a one-to-one socket replacement, and 2) a QUIC-aware approach that opens a fresh stream per call. ## 🍔🧠 How OpenAI Built GPT-Live for Low-Latency Voice AI DevFeed: [🍔🧠 How OpenAI Built GPT-Live for Low-Latency Voice AI]() Original publisher: [Read original article]() Author: Alexandre Zajac Published: 2026-09-07T15:31:33Z Content type: article Language: en Sources: [Hungry Minds]() Topics: [Conversational AI](), [Low Latency](), [voice ai](), [OpenAI](), [real-time](), [Streaming](), [Remote Procedure Call (RPC)](), [Go]() Tags: [go](), [low-latency](), [openai](), [real-time](), [rpc](), [software-engineering](), [streaming](), [voice-ai]() ### AI overview The article explains how OpenAI built GPT-Live as a low-latency, full-duplex voice system. It describes a fast audio path that listens and speaks simultaneously, asynchronous delegation of deeper reasoning and backend work, stateful handoffs, optimized protocol boundaries, and a Go-based media frontend. ### Source excerpt PLUS: Zero-knowledge proofs ⚡, Design.md agent automation 👨💻, System Design Docs 101 📚 ## MCP Logging in Spring AI DevFeed: [MCP Logging in Spring AI]() Original publisher: [Read original article]() Author: Burak Gökmen Published: 2026-09-06T23:19:21Z Content type: tutorial Language: en Sources: [Baeldung]() Topics: [Model Context Protocol](), [log management](), [AI Development](), [Remote Procedure Call (RPC)](), [telemetry]() Tags: [logging](), [mcp](), [mcp-server](), [opentelemetry](), [popular](), [rpc](), [spring](), [spring-ai](), [spring-ai-mcp-popular](), [spring-boot](), [tutorial]() ### AI overview A tutorial on MCP logging in Spring AI, covering server-to-client log notifications, client-controlled severity levels, and migration guidance following the feature's deprecation. ### Source excerpt Learn about MCP logging in Spring AI, both in an MCP server and a client. The post MCP Logging in Spring AI first appeared on Baeldung. ## Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads DevFeed: [Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads]() Original publisher: [Read original article]() Author: Jeffrey Ying Published: 2026-09-01T18:30:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Remote Procedure Call (RPC)](), [Caching]() Tags: [cache](), [kubernetes](), [memory](), [releases](), [rpc](), [streaming]() ### AI overview Kubernetes v1.37 promotes etcd RangeStream to beta. With etcd v3.7, streamed collection reads reduce and stabilize memory use by processing chunks instead of assembling entire pages. ### Source excerpt I am excited to announce that etcd RangeStream is graduating to beta in Kubernetes v1.37. Paired with etcd v3.7, it reduces the memory the API server and etcd need to read a large collection, and makes peak usage more predictable. The cost of large reads The API server serves most list and watch requests from its in-memory watch cache. Populating that cache requires reading a resource's full state from etcd, at startup and on every re-initialization. For a resource with many objects, or large ones, such as Pods, that read is expensive. The API server already paginated these reads, asking etcd for a fixed number of keys at a time rather than the whole collection at once. But a page bounded by key count has no awareness of object size, so a page of large objects can still be very large. That makes memory usage hard to predict, and a bad combination of object size and concurrent reads can be enough to trigger an OOM. etcd's unary Range assembles each page in full before sending it, and the API server holds it while decoding, so the same payload sits in memory on both sides at once. Most of that cost lands on etcd, which is also where streaming helps most. Streaming reads with RangeStream etcd v3.7 adds a streaming version of that read, the RangeStream RPC. It takes the same RangeRequest as Range and returns the same result set, but instead of building the whole response up front, etcd splits it into chunks and streams them. Chunk size is tuned adaptively to the values being returned, so a collection of large objects is bounded by bytes rather than by a key count, and memory is freed as the stream progresses instead of being held until a whole page is assembled. When the feature is enabled, the API server uses RangeStream wherever it reads a whole collection out of etcd. This includes watch cache initialization, and the fallback paths where a list request cannot be served from the cache and reads etcd directly. In either case the API server decodes each chunk as it arri ## 【etcd】写入路径深读：Txn、mod revision 与 quota/alarm DevFeed: [【etcd】写入路径深读：Txn、mod revision 与 quota/alarm]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Back end](), [Raft](), [Remote Procedure Call (RPC)](), [maintenance]() Tags: [alarm](), [apiserver](), [applied-index](), [apply](), [batch](), [bbolt](), [committed-index](), [compaction](), [defrag](), [distributed](), [errcompacted](), [etcd](), [follower](), [k8s](), [kubernetes](), [mod-revision](), [nospace](), [quota](), [revision](), [txn](), [v3-5](), [v3-5-33]() ### AI overview This tutorial explains the etcd v3.5.33 write path from gRPC requests through Raft proposal, quota checks, MVCC apply, and ModRevision assignment. It also describes proposal backpressure, backend quota accounting, and how a NOSPACE alarm blocks writes while reads, deletes, and maintenance operations can continue. ### Source excerpt 走读 etcd v3.5.33 写入路径：raftRequest 背压、Txn compare/mod 与 ModRevision 分配、backend quota 与 NOSPACE alarm 如何把集群推入只读。 ## 【etcd】Lease 与 KeepAlive：TTL、checkpoint 与 Leader 切换 DevFeed: [【etcd】Lease 与 KeepAlive：TTL、checkpoint 与 Leader 切换]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes](), [Remote Procedure Call (RPC)]() Tags: [api](), [checkpoint](), [client](), [concurrency](), [distributed](), [etcd](), [follower](), [k8s](), [keepalive](), [kubernetes](), [lease](), [lessor](), [primary](), [raft](), [ttl](), [v3](), [v3-5-33](), [watch]() ### AI overview This article explains etcd v3.5.33 lease behavior, focusing on the lessor's primary, demote, and promote roles, the KeepAlive renewal path that normally bypasses Raft, lease checkpointing, and TTL changes during leader transitions. It also discusses implications for Kubernetes Node Leases and distributed locks. ### Source excerpt 钉 etcd v3.5.33 lessor 的 primary/demote/promote、KeepAlive 不经 Raft 的 Renew 路径、LeaseCheckpoint 与 Promote 时 TTL 展期，以及 Leader 切换对 Node Lease 的排障落格。 ## 【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted DevFeed: [【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Remote Procedure Call (RPC)](), [Kubernetes]() Tags: [apiserver](), [apply](), [compaction](), [distributed](), [errcompacted](), [etcd](), [io](), [k8s](), [kubernetes](), [lag](), [leader](), [lease](), [mvcc](), [notify](), [raft](), [range](), [restore](), [revision](), [rpc](), [v3-5](), [v3-5-33](), [watch](), [watchablestore]() ### AI overview This article examines the etcd v3.5.33 watchableStore implementation, including synced and unsynced watcher groups, victims caused by backpressure, Apply-time notification, historical synchronization, and the ErrCompacted client resynchronization boundary. It also discusses event ordering, follower watch progress, and interactions with Kubernetes apiserver watch caches. ### Source excerpt 钉 etcd v3.5.33 watchableStore 的 synced/unsynced/victims 三分法、Apply 后 notify 与历史追赶 syncWatchersLoop，以及 CompactRevision 触发 ErrCompacted 时的客户端重同步边界。 ## Develop and test MCP in Postman: jhipster-mcp in action DevFeed: [Develop and test MCP in Postman: jhipster-mcp in action]() Original publisher: [Read original article]() Author: Anthony Viard Published: 2026-08-19T16:00:00Z Content type: article Language: en Sources: [Postman Blog]() Topics: [Model Context Protocol](), [Postman](), [Spring Boot](), [Node.js](), [TypeScript](), [Angular](), [React](), [Vue.js](), [JSON](), [Remote Procedure Call (RPC)]() Tags: [ai-agents](), [angular](), [apache](), [cli](), [general](), [jhipster](), [json](), [mcp](), [node-js](), [open-source](), [post](), [react](), [rpc](), [spring-boot](), [typescript](), [vue]() ### AI overview This Postman developer article demonstrates jhipster-mcp, an open-source MCP server that exposes the JHipster generator to MCP clients. It uses Postman's MCP client to test tools, prompts, and resources for generating and evolving Spring Boot applications from JDL. ### Source excerpt Drive the jhipster-mcp server from Postman's MCP client to test tools, prompts, and resources before handing them to an AI agent. Try it today. The post Develop and test MCP in Postman: jhipster-mcp in action appeared first on Postman Blog. ## Go SDK для YDB: уменьшаем количество запросов к СУБД для интерактивных транзакций DevFeed: [Go SDK для YDB: уменьшаем количество запросов к СУБД для интерактивных транзакций]() Original publisher: [Read original article]() Author: spesternikov (Яндекс, Yandex Cloud & Yandex Infrastructure, YDB) Published: 2026-08-13T13:23:34Z Content type: tutorial Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [Go](), [SDKs](), [Transactions](), [Remote Procedure Call (RPC)]() Tags: [go](), [rpc](), [sdk](), [tag-8288660a1e40](), [tag-89f0c6f39f5d](), [tag-d4be1d74f775](), [transactions](), [ydb]() ### AI overview This Russian-language technical article explains how Yandex's YDB Go SDK reduces network round-trips for interactive transactions. It describes combining transaction startup with the first query through Lazy Transactions and notes that the improvements were included in Go SDK releases v3.126.0 and v3.126.5. ### Source excerpt Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service. Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса. В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться. Читать далее ## Thank You for 40 000 Stars on GitHub DevFeed: [Thank You for 40 000 Stars on GitHub]() Original publisher: [Read original article]() Author: The DuckDB team Published: 2026-08-05T00:00:00Z Content type: article Language: en Sources: [DuckDB]() Topics: [GitHub](), [SQL](), [Remote Procedure Call (RPC)](), [Embeddings](), [Internet of things](), [Streaming]() Tags: [announcements](), [blog](), [community](), [developer](), [development](), [duckdb](), [ecosystem](), [embeddings](), [events](), [features](), [github](), [performance](), [production](), [release](), [sql](), [streaming](), [video]() ### AI overview DuckDB celebrates reaching 40,000 GitHub stars by reviewing recent ecosystem growth, including DuckDB 1.4.0 and 1.5.0, the DuckLake 1.0 standard, the Quack remote protocol, community metrics, meetups, developer events, and community projects involving search, embeddings, IoT, and streaming analytics. ### Source excerpt DuckDB just reached 40 000 stars on GitHub! Here's what happened since the last 10 000-star milestone. ## When does the A2A protocol actually matter? DevFeed: [When does the A2A protocol actually matter?]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-08-04T00:00:00Z Content type: article Language: en Sources: [Redis Blog]() Topics: [Protocol (disambiguation)](), [Model Context Protocol](), [Remote Procedure Call (RPC)](), [Security](), [JSON](), [Authentication](), [Web]() Tags: [authentication](), [http](), [json](), [mcp](), [model-context-protocol](), [rpc](), [security](), [server](), [tech-de]() ### AI overview A2A is an open standard for communication between independently deployed agents, particularly when they are owned by different teams or vendors. The article presents an ownership test for deciding whether A2A is needed, explains its security model and core primitives, and contrasts it with MCP. ### Source excerpt If you're building multi-agent systems, someone has probably asked whether you're "doing A2A yet," with the implication that you should be. When teams actually reach for it, most can't say why they need A2A over MCP. A more useful question: do your ag... ## What's new in the MCP 2026-07-28 specification DevFeed: [What's new in the MCP 2026-07-28 specification]() Original publisher: [Read original article]() Author: Aditya Oberai Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Appwrite Blog]() Topics: [Model Context Protocol](), [MCP Server](), [HTTP](), [Routing (disambiguation)](), [Caching](), [Authorization](), [Remote Procedure Call (RPC)]() Tags: [caching](), [http](), [mcp](), [mcp-server](), [model-context-protocol](), [news](), [routing](), [rpc]() ### AI overview The article explains changes in the MCP 2026-07-28 specification, focusing on the move from stateful sessions to a stateless request/response core. It covers implications for routing, load balancing, caching, authorization, and server migration. ### Source excerpt The MCP 2026-07-28 spec drops sessions, adds header based routing, cacheable lists, and MRTR. Here is what changed and what you need to migrate your servers. ## Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need? DevFeed: [Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need?]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-07-22T00:00:00Z Content type: comparison Language: en Sources: [Redis Blog]() Topics: [Model Context Protocol](), [Remote Procedure Call (RPC)](), [Artificial Intelligence](), [JSON](), [Large Language Model](), [Orchestration](), [observability](), [servers](), [Grafana]() Tags: [agent](), [api](), [architecture](), [developer](), [developer-tooling](), [grafana](), [guide](), [json](), [mcp](), [model-context-protocol](), [observability](), [rpc](), [tech-de]() ### AI overview This guide compares the Model Context Protocol (MCP) with Agent2Agent (A2A), explaining that MCP connects an LLM application to tools and data while A2A connects independent agents. It describes MCP's hosts, clients, servers, tools, resources, prompts, JSON-RPC transport, streaming, production use cases, and governance limitations. ### Source excerpt Somewhere around your third agent, someone in a design review asks, "Shouldn't we be using A2A for this?" It's a fair question that most teams can't answer well, because the two big agent protocols keep getting lumped together when they solve differen... ## 5 agent architecture scenarios: assess MCP vs. A2A DevFeed: [5 agent architecture scenarios: assess MCP vs. A2A]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-07-22T00:00:00Z Content type: article Language: en Sources: [Redis Blog]() Topics: [Model Context Protocol](), [Remote Procedure Call (RPC)](), [JSON](), [Large Language Model](), [anthropic]() Tags: [agent](), [anthropic](), [apis](), [architecture](), [article](), [data](), [external](), [json](), [llms](), [mcp](), [rpc](), [server](), [tech-de]() ### AI overview An analysis of five agent architecture scenarios, using the boundary between an agent and external tools or data, and the boundary between agents, to clarify when MCP or A2A is appropriate. It explains MCP's client-host-server model and JSON-RPC exchanges, contrasts it with A2A, and emphasizes that neither protocol is universally required. ### Source excerpt We've watched enterprise teams go from vague "we might do agent stuff" conversations to full internal agent environments in a matter of months, and the same protocol question comes up in almost every one: does the design need the Model Context Protoco... ## Announcing etcd v3.7.0 DevFeed: [Announcing etcd v3.7.0]() Original publisher: [Read original article]() Author: SIG Etcd Leads Published: 2026-07-08T12:00:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [releases](), [Database](), [Kubernetes](), [Latency](), [Remote Procedure Call (RPC)]() Tags: [changelog](), [cpu](), [database](), [kubernetes](), [latency](), [memory](), [performance](), [release](), [releases](), [rpc]() ### AI overview etcd v3.7.0 is a minor release of the distributed key-value store used as a core Kubernetes component. It introduces RangeStream for chunked large result sets, improves performance and leases, removes the legacy v2store, and completes a protobuf overhaul. ### Source excerpt This article is a mirror of the original announcement Today, SIG etcd is releasing etcd v3.7.0, the latest minor release of the popular distributed key-value store and core Kubernetes component. v3.7 ships the long-requested RangeStream feature, delivers several other performance improvements, removes the last remnants of the legacy v2store, and completes a major protobuf overhaul. You can download etcd v3.7.0 here: Source code Binaries Official container images This release also includes new versions of the two core etcd dependencies, bbolt v1.5.0 and raft v3.7.0. For instructions on installing etcd, see the install documentation. For the full list of changes, see the etcd v3.7 changelog. A heartfelt thank you to all the contributors who made this release possible! Major features The most significant changes in v3.7.0 include: RangeStream -- stream large result sets in chunks instead of buffering the whole response. Keys-only range requests, faster and more reliable leases, and several other performance improvements. etcd now boots entirely from v3store, eliminating a long-standing dependency on the legacy v2 store A completed protobuf overhaul, replacing outdated protobuf libraries with fully supported ones. etcd v3.7 ships with bbolt v1.5.1 and raft v3.7.0. FeaturesRangeStream In etcd v3.6 and earlier, it is challenging to work with requests that return large result sets. The database would buffer the full result set before sending, leading to unpredictable latency and memory usage, both on the server and the client. The RangeStream RPC lets calling applications accept result sets in chunks, reducing latency and making buffering memory usage more predictable. Instructions on how to use RangeStream in gRPC calls and in etcdctl can be found in the etcd documentation. Users should try it out for their own applications. In coordinated releases, the RangeStream feature will become available to users running the upcoming v1.37 of Kubernetes by enabling the EtcdRangeStre ## Security Baked Into the JVM: why fork Apache River and OpenJDK? DevFeed: [Security Baked Into the JVM: why fork Apache River and OpenJDK?]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-06-28T00:00:00Z Content type: opinion Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [Java](), [openjdk](), [Architecture & Design](), [Remote Procedure Call (RPC)](), [Networks]() Tags: [authorization](), [dirtychai](), [discovery](), [distributed](), [ipv6](), [java](), [jgdms](), [jini](), [jvm](), [lock-free](), [microservices](), [openjdk](), [rpc](), [security](), [self-healing](), [technical]() ### AI overview This article introduces DirtyChai, a community fork of OpenJDK that restores Java authorization infrastructure, and JGDMS, a security-hardened fork of Apache River for dynamically discoverable microservices over IPv6. It argues that distributed systems require security beyond network firewalls and outlines the projects' complementary roles, including authorization, service discovery, hardened deserialization, transport security, proxy trust verification, and codebase safety checks. ### Source excerpt The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn't notice. ## Bringing Temporal into your AI editor: How Coinbase debugs Workflows with MCP DevFeed: [Bringing Temporal into your AI editor: How Coinbase debugs Workflows with MCP]() Original publisher: [Read original article]() Author: Edward Zhu Published: 2026-05-26T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Model Context Protocol](), [coinbase](), [MCP Server](), [Artificial Intelligence](), [Python](), [API keys](), [Self-hosted](), [JSON](), [Cloud](), [Remote Procedure Call (RPC)]() Tags: [ai](), [api-keys](), [coinbase](), [how-to](), [json-rpc](), [mcp](), [mcp-server](), [python](), [self-hosted]() ### AI overview Coinbase describes a custom, read-only Temporal MCP server that lets engineers investigate workflow failures from an AI editor using natural-language queries. The server provides 10 tools, supports Temporal Cloud and self-hosted clusters, and runs locally over MCP stdio communication. ### Source excerpt How Coinbase engineers debug Temporal Workflows from their AI editor: a custom MCP server, 10 read-only tools, and 14,000+ calls in a couple of months. ## Announcing etcd 3.7.0-beta.0 DevFeed: [Announcing etcd 3.7.0-beta.0]() Original publisher: [Read original article]() Author: SIG-etcd Leads Published: 2026-05-20T00:00:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Databases](), [Remote Procedure Call (RPC)](), [Kubernetes](), [Refactoring](), [Code quality]() Tags: [availability](), [code-quality](), [database](), [kubernetes](), [latency](), [refactoring](), [release](), [rpc]() ### AI overview The article announces the first beta release of etcd v3.7.0, introducing the RangeStream RPC for processing large result sets in chunks. It also describes legacy-component cleanup, the removal of v2store, and expected upgrade compatibility issues. ### Source excerpt SIG-Etcd announces the availability of the first beta release of etcd v3.7.0. This new version of the popular distributed database and key Kubernetes component includes the long-requested RangeStream feature, as well as a refactoring and cleanup of multiple legacy components and interfaces. v3.7 will deliver improved security, better operational reliability, and an improved experience for working with large resultsets. First, however, the project needs users to test the beta. You can find v3.7.0-beta.0 here: Source code Binaries Official container images Please try it out and report issues in the etcd repo. This beta also determines the EOL of version 3.4. RangeStream In etcd v3.6 and earlier, it is challenging to work with requests that return large resultsets. The client or requesting application is forced to wait for the full result set, leading to unpredictable latency and memory usage. The RangeStream RPC lets calling applications accept result sets in chunks, reducing latency and making buffering memory usage more predictable. Much of the work on RangeStream was done by a relatively new contributor to etcd, Jeffrey Ying, a software engineer at Google. New contributors can have a substantial impact on etcd development. "I've always been fascinated by database internals, and building RangeStream was a great opportunity to solve a bottleneck we were hitting in production with Kubernetes. It was the perfect opportunity to collaborate across projects and improve the ecosystem as a whole. Jumping into etcd as a new contributor had a bit of a learning curve, but the community is incredibly welcoming. The leads were very receptive to my ideas and helped me iterate quickly, while maintaining the project's high bar for reliability and code quality," said Jeffrey. Instructions on how to use RangeStream in gRPC calls and in etcdctl can be found in the etcd documentation. Users should try it out for their own applications. Removal of v2store The last vestiges of etcd v2sto ## Inside the Google ADK and Temporal integration DevFeed: [Inside the Google ADK and Temporal integration]() Original publisher: [Read original article]() Author: Drew Hoskins Published: 2026-04-20T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Agent Framework](), [Artificial Intelligence](), [Google](), [Development](), [Python](), [Remote Procedure Call (RPC)](), [JSON](), [vercel ai sdk](), [OpenAI]() Tags: [agent-development-kit](), [agent-framework](), [agents](), [ai](), [announcements](), [distributed](), [google-adk](), [http](), [integration](), [json-rpc](), [python]() ### AI overview This article explains Temporal's integration with Google ADK. It describes Temporal as the durable execution layer while Google ADK provides the agent framework, and outlines an initial Python implementation using independent HTTP services and A2A JSON-RPC requests. The article also places the integration alongside Temporal's OpenAI Agents SDK and Vercel AI SDK integrations. ### Source excerpt Google ADK builds the agent and Temporal makes sure it finishes. Here's how our integration works under the hood and all it took to make it happen. ## Announcing Lix 2.95 "Kakigōri" DevFeed: [Announcing Lix 2.95 "Kakigōri"]() Original publisher: [Read original article]() Published: 2026-03-25T00:00:00Z Content type: release Language: en Sources: [News on Lix]() Topics: [releases](), [Cap'n Proto](), [Remote Procedure Call (RPC)](), [Nix]() Tags: [bugfixes](), [documentation](), [improvements](), [performance](), [release](), [rpc](), [upgrade](), [version]() ### AI overview The Lix team announces version 2.95, "Kakigōri," a major release focused on bug fixes, quality-of-life improvements, documentation, performance, and continued integration with the Cap'n Proto RPC runtime. The article also describes upgrade guidance and ongoing work toward additional RPC protocols. ### Source excerpt We at the Lix team are proud to announce our sixth major release, version 2.95 "Kakigōri". This release focuses on long-awaited bugfixes, quality-of-life improvements, documentation, performance improvements and continued integration of Lix with the Cap'n'Proto remote procedure call runtime to replace the previous bespoke implementation. ## Transitioning from REST to gRPC: System Design and Tradeoffs DevFeed: [Transitioning from REST to gRPC: System Design and Tradeoffs]() 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: [gRPC](), [Remote Procedure Call (RPC)](), [Code](), [HTTP](), [JSON]() Tags: [api-design](), [client](), [grpc](), [http](), [json](), [microservices](), [protobuf](), [rest](), [rpc](), [schema](), [server](), [system-design]() ### AI overview This tutorial explains how gRPC uses .proto service definitions and Protocol Buffers to generate typed client and server code, serialize messages, and communicate over HTTP/2. It compares gRPC with REST and recommends gRPC for internal service-to-service calls needing low latency, schema-first contracts, or streaming, while retaining REST with JSON at the edge for browsers and external consumers. ### Source excerpt gRPC defines services in a .proto file, compiles them into typed client and server code, and transports binary protobuf over HTTP/2. Choose it for internal service-to-service calls that need low latency, schema-first contracts, or streaming, and keep REST with JSON at the edge where browsers and external consumers live. ## gRPC vs. REST: Key Differences, Performance, and Use Cases DevFeed: [gRPC vs. REST: Key Differences, Performance, and Use Cases]() Original publisher: [Read original article]() Author: LASZLO GYORI, SOLUTION ARCHITECT @ TOPTAL Published: 2026-03-10T04:00:00Z Content type: comparison Language: en Sources: [Toptal Blog]() Topics: [Remote Procedure Call (RPC)](), [distributed-systems](), [Microservice]() Tags: [api](), [architecture](), [complexity](), [distributed-systems](), [framework](), [guide](), [http](), [latency](), [microservices](), [performance](), [scalability]() ### AI overview A comparison of gRPC and REST APIs that focuses on performance, operational trade-offs, and selecting an approach for distributed systems and microservices. ### Source excerpt Trying to decide between gRPC and REST? This guide goes beyond surface comparisons to focus on the performance and operational trade-offs that determine which API framework is right for your next build. ## Anatomy of a trace DevFeed: [Anatomy of a trace]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-03-02T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [tracing](), [Traces](), [telemetry](), [API](), [Databases](), [Cache](), [Remote Procedure Call (RPC)](), [HTTP](), [SQL](), [Authentication]() Tags: [api](), [authentication](), [cache](), [database](), [distributed](), [http](), [request](), [rpc](), [sql](), [trace](), [tracing]() ### AI overview This article explains how distributed traces are built as requests move through services and operations. It describes root and child spans, trace IDs, automatic context propagation, and the operation-specific data captured by Encore's runtime, including API calls, RPCs, database queries, cache writes, and outbound HTTP calls. ### Source excerpt What actually happens when a request hits your application, and what a distributed trace captures at every step. ## SFQ: Simple, Stateless, Stochastic Fairness DevFeed: [SFQ: Simple, Stateless, Stochastic Fairness]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2026-02-25T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Algorithms](), [distributed-systems](), [Remote Procedure Call (RPC)](), [Network](), [systems]() Tags: [algorithms](), [customer](), [distributed-systems](), [network](), [queuing](), [rpc]() ### AI overview The article explains Stochastic Fairness Queuing (SFQ), an algorithm for isolating workloads from different customers and mitigating noisy-neighbor effects with O(1) queues and O(1) time. It contrasts SFQ with per-client fairness queuing, explains hash-based queue assignment and periodic hash perturbation, and discusses applying the approach to network traffic, RPC requests, single-host services, and load balancing across hosts. ### Source excerpt SFQ: Simple, Stateless, Stochastic Fairness Roll the dice. Paul E. McKenney's 1990 paper Stochastic Fairness Queuing contains one of my favorite little algorithms for distributed systems. Stochastic Fairness Queuing is a way to stochastically isolate workloads from different customers in a way that significantly mitigates the effects of noisy neighbors, with O(1) queues and O(1) time. McKenney starts by describing Fairness Queuing (or queue per client): This fairness-queuing algorithm operates by maintaining a separate first-come-first-served (FCFS) queue for each conversation. ... Since the queues are serviced in a bit-by-bit round-robin fashion ill-behaved conversations that attempt to use more than their fair share of network resources will face longer delays and larger packet-loss rates than well-behaved conversations that remain within their fair share. That's a network packet focused view, but the same thing can apply to RPC requests, for example, just by using a different key (e.g. the authorized customer id). The big downside of this in distributed systems is that it requires O(customers) queues, and the related O(customers) work of doing round-robin across those queues. Stochastic fairness queuing can be most easily understood by comparing it to strict fairness queuing. The major differences are that the queues are serviced in strict round-robin order and that a simple hash function is used to map from source-destination address pair into a fixed set of queues. In SFQ, on the other hand, a fixed set of queues is used (so O(1) queues, not O(customers) queues), and customers are assigned to the queues based on a hash. That's great, but still causes the problem of long-term bad luck. If I end up on a queue with a noisy neighbor, I end up there forever. If two conversations collide, they will continue to collide, resulting in each conversation of the pair persistently receiving less than its share of bandwidth. This situation is deviated by periodically perturbin [Next page]()