<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on gNMIc Operator</title><link>https://fbe70dc2.gnmic-operator2.pages.dev/tags/architecture/</link><description>Recent content in Architecture on gNMIc Operator</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 17 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://fbe70dc2.gnmic-operator2.pages.dev/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing Telemetry Pipelines</title><link>https://fbe70dc2.gnmic-operator2.pages.dev/blog/2026-03-17-telemetry-pipeline-design/</link><pubDate>Tue, 17 Mar 2026 00:00:00 +0000</pubDate><guid>https://fbe70dc2.gnmic-operator2.pages.dev/blog/2026-03-17-telemetry-pipeline-design/</guid><description>&lt;p>Managing gNMI telemetry at scale is not just a configuration problem. It&amp;rsquo;s an ownership problem. Subscriptions change often. Targets come and go. Different teams care about different slices of the network. And when your collector fleet spans multiple pods serving hundreds of devices, the last thing you want is a design where updating a Kafka output triggers a rolling restart, or where scaling from 3 to 5 pods means touching your telemetry wiring.&lt;/p></description></item></channel></rss>