THE SIGNAL: What matters in distributed systems | #1
March 2026 | Issue #1
Welcome to SIGNAL. This is a monthly briefing for CTOs, VP Engineering, and Chief Architects running distributed systems at scale. We don’t aggregate news. We aggregate lessons.
Every month: one architecture debate with real trade-offs, one production war story with solutions, and three critical signals with business context. No hype cycles. No vendor pitches. Just what you need to know to make better infrastructure decisions.
This month: Akka launches an Agentic AI platform with MCP integration — the same week Perplexity’s CTO publicly dumps the protocol. The MCP backlash intensifies as the dev world argues whether it’s enterprise governance or unnecessary overhead.
Today
- Akka launches Agentic AI on MCP Akka launches its Agentic AI stack on MCP — while Perplexity’s CTO is publicly distancing the company from the protocol.
- KIP-1150 makes diskless Kafka official — two paths to S3-backed streaming converge
- Kafka 4.2 graduates Share Groups — scale consumers by workload, not partition count
- Scala 3.8 locks in JDK 17, 3.9 LTS approaches with the same floor
- Time to start testing sbt 2.0 RCs and standardizing with the now-official Scala CLI 1.0.
The Architecture Debate: MCP Protocol — Enterprise Governance or Overhead?
Akka isn’t just shipping slides about agents anymore, it’s shipping production runtimes. After announcing the Akka Agentic Platform in 2025 – with Orchestration for complex multi-agent workflows, Agents with MCP/API support, Memory as durable sharded state, and Streaming for real-time AI – the stack starts landing inside large, regulated enterprises that care about SLAs and governance instead of yet another data science POC. By 2026 you’re already seeing big deployments like Manulife, where Akka becomes the runtime for an enterprise agentic AI platform rather than a sidecar experiment.
The same week, on the other side of the spectrum, Perplexity makes a very public move in the opposite direction. Denis Yarats announces at Ask 2026 that they’re dropping MCP internally in favor of plain APIs and CLIs. The critique is strictly operational: MCP tool definitions burn context window (often an order of magnitude more tokens than an equivalent CLI call), auth is clunky, and the protocol adds another abstraction layer on top of APIs that already exist and are well understood by infra teams.
That’s where the split nobody talks about shows up. MCP really has two faces. In stdio mode it runs locally on your laptop and behaves like “CLI with contracts” – great for a single developer, but with no central visibility. In remote HTTP mode, MCP turns into a shared tool server: one place to manage auth, catalog tools, and keep prompts and policies consistent across teams. The backlash lumps both modes together. CLIs run as you – your credentials, your permissions, no shared audit trail. For one engineer on a dev machine, that’s fine. For 50 engineers touching production, it’s a governance incident waiting to happen.
Scalac angle: the framing of “MCP vs CLI” is wrong. The real axis is governance versus speed. If you’re building internal tools with a handful of fixed integrations and a small team, classic APIs and CLIs are faster to wire up and cheaper to run. In multi-tenant enterprise environments that need centralized auth, observability, and audit trails, MCP starts to earn its overhead. Smart teams don’t pick “MCP or CLI” – they use CLIs where the model already understands the tool, and MCP where they need a unified, controlled access layer. The protocol was overhyped early on, but its real story was always enterprise adoption, not the solo dev hacking on a laptop.
🔗 Manulife Selects Akka to Operationalize Agentic AI · Perplexity: MCP vs APIs for AI Agents · Perplexity Agent API MCP Shift
Notes from the Trenches: Kafka 4.2 — Diskless Topics and Share Groups
Apache Kafka approves KIP-1150. The community voted yes on March 2nd, making diskless topics officially part of the roadmap. Brokers serve partitions directly from object storage using a leaderless architecture.
The catch: production readiness is unlikely before 2027. KIP-1164 (Batch Coordinator) and sub-proposals still need implementation.
Confluent acquired WarpStream in January. The proprietary fork already delivers order-of-magnitude cost reductions reported by early adopters for log analytics workloads, with latencies in the 100-500ms range — fine for logs, unacceptable for sub-50ms p99 transactions.
The migration decision: KIP-1150 offers gradual, topic-by-topic migration. WarpStream requires ripping out brokers entirely. Greenfield teams choose between vendor lock-in today (WarpStream works now) versus migration complexity tomorrow (KIP-1150 is unlikely before 2027).
Scalac angle: Existing Kafka estates should wait for KIP-1150. Running both systems defeats the purpose. Greenfield without latency constraints? WarpStream carries less risk than betting on 2027 timelines. The decision is organizational tolerance for vendor lock-in versus timeline uncertainty — not which technology is “better.”
The partition-to-consumer binding has been Kafka’s fundamental scaling constraint since 2011.
With 4.2.0, KIP-932 graduates to production-ready, introducing Share Groups that decouple parallelism from partition count.
The Problem: A topic with 12 partitions maxed out at 12 concurrent consumers. Need more throughput? You re-partition — a destructive operation requiring downtime and backfill.
The Solution: Share Groups use cooperative consumption with individual acknowledgment tracking. Multiple consumers can now process records from the same partition concurrently, with the broker managing delivery counts and lock timeouts. (KIP-1222 proposes lease extensions for long-running tasks — a separate proposal still under development.)
Migration Reality: Share Groups require new consumer clients (4.2+) and explicit opt-in. Existing consumer groups work unchanged. The critical change is operational: you can now scale consumers based on CPU/memory constraints rather than partition geometry.
Scalac angle: Test Share Groups on your heaviest read workloads — the ones where you’ve been forced to over-partition to achieve parallelism. Use share.acquire.mode=record_limit for strict memory limits. Don’t migrate everything. Use Share Groups for the 20% of topics that need elastic scaling, keep traditional groups for the 80% where partition affinity matters.
Signal Over Noise: Three Critical Changes This Month
Scala 3.8.2 stabilizes the JDK 17 transition
Scala 3.8 shipped on January 21, 2026 with two firsts: a JDK 17 baseline and the standard library compiled in Scala 3. State of Scala 2026 explicitly recommends 3.8.1+ and points to 3.8.2 as the point where early runtime regressions are resolved, positioning 3.8.x as the practical bridge toward 3.9 LTS in Q2 2026.
Practical takeaway: new services should now default to Scala 3.8.x on JDK 21 LTS, while libraries that must support JDK 8 keep cross‑compiling against 3.3 LTS until 3.9 LTS lands.
sbt 2.0 moves from „someday” to „start testing now”
State of Scala 2026 notes sbt 2.0.0 RC builds (up to RC8 as of early February) and calls out tangible build‑performance improvements versus 1.x, especially for Scala 3 projects.
The same report highlights sbt 2.0.0‑M4 and later RCs as production‑like enough to warrant testing in CI, rather than treating sbt 2.x as a distant future.
Practical takeaway: if sbt is your standard, reserve time in Q2 2026 to trial sbt 2.0 on non‑critical services, tune CI caching, and clean up custom plugins that rely on 1.x internals.
Community Voice: What They’re Saying on Reddit
r/scala on Scala 3.8 and JDK 17+: Discussions around the „Scala 3 will require JDK 17+ from 3.8” announcement show many teams planning to keep 3.3 LTS for legacy while moving new work to 3.8.x, accepting minor breaking changes (like betterFors) as the cost of finally standardizing on JDK 17+.
r/scala on tooling: Weekly threads and newsletters (like This Week in Scala) keep circling back to the same theme: sbt 2.0 RCs and Scala CLI 1.0 are good enough that teams should stop treating their build setups as untouchable snowflakes and start converging on a small number of supported paths.
In the Know
State of Scala 2026 highlights that 92% of surveyed teams report some Scala 3 use, but many still run mixed 2.x/3.x estates, with 3.8.x and the upcoming 3.9 LTS seen as the moment to finally standardize.
On the JVM side more broadly, recent Java round‑ups and performance updates emphasize JDK 26 GA and JEP‑516’s ahead‑of‑time object caching with any GC, underlining that future performance wins will come from staying current on the JDK, not just tuning old runtimes harder.
Top Resources
Article: „State of Scala 2026” – a concise overview of Scala 3.8, the 3.9 LTS roadmap, sbt 2.0 status, Scala CLI 1.0 and the Akka/Pekko landscape, with concrete „actions for 2026” you can turn into platform OKRs.
betterFors stabilizes. For-comprehension desugaring changes.Paper: Automating Skill Acquisition of Agentic Repositories – AI models fail on complex multi-step tasks because they lack reusable procedural knowledge. This paper shows that automatically extracting standardised skills from open-source repositories improves task completion efficiency by 40% while staying at human-level output quality. If your team is building internal coding assistants or agent tooling on top of JVM infrastructure, the skill extraction architecture here is the baseline to benchmark against.
Signal is published by Scalac. We build distributed systems for teams who ship.
What is SIGNAL? A monthly briefing for senior engineering leaders. Three sections: Architecture Debate, Notes from the Trenches, Signal Over Noise. No hype. No vendor pitches. Just lessons that matter.
References
Authors
Popular Posts in category
THE SIGNAL: What matters in distributed systems | #2
