GitHub user hanishi edited a discussion: Pekko Ad Network(promovolve)
I’m currently working on a publisher-centric, context-based ad network built on Apache Pekko Cluster. The project is still in active development, but it is intended to be fully open source. I plan to disclose architectural details and share the repository once it is ready. Promovolve is meant to show what Akka/Pekko can actually build when it’s used as a runtime rather than just a convenient toolkit. A lot of systems that moved away after the license change could do so because actors were mainly used as a threading or batch-execution model. That usage was never “wrong”because Akka was explicitly positioned as a toolkit, and partial adoption was always valid. But that part is also the easiest to replace. What tends to be overlooked is the value of the full cluster model. When you commit to this you can build an entire production system with one coherent set of ideas, without stitching together a large collection of unrelated frameworks. Promovolve is intentionally built that way. It’s a complete ad-serving runtime that relies primarily on cluster semantics. The point isn’t that other approaches are wrong, but that the cluster model already gives you all of that, if you let it. Used this way, Akka/Pekko isn’t just a convenience layer, but most simple examples fail to show this, because they stop at actors as a concurrency tool and never reach the cluster semantics where that architectural value actually appears. I felt that going beyond examples and building something fully production-ready would attract practitioners, and that real usage would naturally bring in stakeholders later, thereby increasing Pekko's visibility. While ad tech can be seen as niche, it’s where I’ve spent most of my career, and it’s a domain with a clear path to real revenue. ## Adaptive Budget Pacing Demonstrating ad budget pacing that works across all traffic levels. It's a feature I am currently working on. https://www.youtube.com/watch?v=wBhUKKP5LC8 On the left is the ad network. On the right is a traffic simulator. All configuration of the ad network on the left can be done via APIs. Creatives are registered directly on a CDN, so the only costs involved are server runtime and CDN fees. If you have a Kubernetes (K8s) environment, anyone can deploy and use it immediately. The management UI and ad slots can be freely implemented by developers; anyone may be able to run an ad business themselves (potentially). This ad network is designed so that no creative is delivered unless the publisher explicitly approves it in advance. Even if an advertiser’s campaign wins the auction, the ad will not be shown unless the publisher has approved that creative, allowing publishers to use the network with confidence. ``` No views Jan 13, 2026 Learned: ▁▁▁▁▁▁▂▂▃▅▄▅▆█▆▅▄▃▃▃▁▅▃[▁] Actual: ▁▁▁▁▁▁▂▂▃▄▅▃█▅▆▆▄▂▂▂▃▆▁[▁] Matches (16/24): h0-8: ▁▁▁▁▁▁▂▂▃ - perfect early hours h14: ▆ h16: ▄ h21: ▆ (evening spike preserved!) h23: ▁ Close (within 1 bar): h9, h10, h15, h17-19 ``` For those unfamiliar with ad pacing: imagine an advertiser has a daily budget of $100 to spend on ads, and traffic to a site is not constant. If the system simply buys every available impression as fast as possible, the entire budget could be spent in the first hour of the day, leaving the advertiser invisible for the remaining 23 hours. Pacing is the control logic that decides when not to buy; deliberately skipping some opportunities early so that spend is spread smoothly across time. This becomes harder when traffic is bursty, feedback is delayed, and prices vary, which is why pacing is fundamentally a control problem, not a simple rule. GitHub link: https://github.com/apache/pekko/discussions/2608 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
