DEV Community: William

Building Choragi: How We Orchestrated a 6-Agent Concert Planning System with Gemini Live and Google Cloud

William — Fri, 13 Mar 2026 11:35:52 +0000

*We created this piece of content for the purposes of entering the Gemini Live Agent Challenge.

GeminiLiveAgentChallenge*

Music has a universal power to heal and bring communities together. But behind every magical live concert is a grueling logistical nightmare. Independent artists and event planners spend weeks scouting venues, making stressful phone calls to negotiate rates, designing promotional materials, and manually wrestling with ad campaigns.

We thought: What if we could build an engine that takes away the logistical burden, turning a month of planning into a 5-minute automated sequence?

Enter Choragi—an autonomous, multi-agent event orchestration system triggered entirely by a natural voice conversation. In this post, I’ll break down how we built this system using Java Spring Boot, Gemini Live API, Google Cloud Run, and the absolute cutting edge of Google's generative AI models.

The Architecture: A Serverless Symphony

Choragi is not a single monolith; it is a highly specialized microservices architecture. We built 6 independent Spring Boot applications and deployed them entirely on Google Cloud Run.

By leveraging Cloud Run, we achieved a scalable, serverless backend where each agent scales independently based on its workload. We secured the entire internal network using Google Cloud's Application Default Credentials (ADC), entirely eliminating the need for hardcoded service account keys in our codebase.

Here is the breakdown of the fleet:

UI Dashboard (ui-client): The real-time WebSockets command center.
Venue Scout (venue-finder): Discovers potential concert spaces.
Live Negotiator (live-negotiator): Telephony agent connecting Twilio to Gemini.
Creative Director (creative-director): Generates 8K posters and cinematic video trailers.
Site Builder (site-builder): Autonomously deploys a live promotional website.
Digital Promoter (digital-promoter): Navigates Google Ads to launch campaigns.

The Brains: Integrating Google AI Models

To make this pipeline truly autonomous, we had to fuse multiple modalities of AI.

1. Real-Time Telephony with Gemini 2.5 Flash Native Audio

The most ambitious part of Choragi was the live-negotiator. We wanted the AI to actually call a venue owner over the phone and negotiate a booking space.

We bridged a Twilio WebSocket stream directly to the Gemini BidiGenerateContent API. Because Twilio streams audio in 8kHz MuLaw format and Gemini strictly requires 16kHz PCM, we had to build an on-the-fly byte transcoder in Java. We utilized the ["AUDIO"] response modality to ensure the model spoke naturally, and we implemented a custom Voice Activity Detection (VAD) algorithm using RMS thresholding to prevent noisy phone lines from interrupting the AI.

2. Multi-Modal Creative Generation

Once the venue is secured, the creative-director agent takes over to generate promotional assets, directly uploading the results to a public Google Cloud Storage bucket.

Tour Posters: We utilized Gemini 2.5 Flash Image to generate highly realistic, professional concert posters that strictly adhered to text prompts for the artist's name and location.
Cinematic Video Trailers: We integrated Vertex AI Veo 3.0 Fast via its Long-Running Operations REST API to generate photorealistic concert stage visuals.

3. Robotic Web Automation with Gemini Vision

For the digital-promoter, we didn't want to use standard APIs. We wanted the agent to navigate the web like a human. Using Microsoft Playwright in a headless Chromium container, the agent literally "looks" at the Google Ads dashboard using Gemini 2.5 Flash. The model analyzes the screenshot of the DOM and outputs precise visual coordinates and text commands (e.g., CLICK_TEXT: Page views, FILL_FIELD: businessName) to autonomously launch the campaign.

The Hardest Technical Challenge: Vertex AI REST Routing

When building hackathon projects, you quickly find the bleeding edge of new APIs. When integrating Veo 3.0 Fast, we bypassed the standard SDK and hit the raw Vertex AI predictLongRunning REST endpoints.

We successfully authenticated and triggered the video generation, receiving an Operation ID (a UUID) to poll for the video's completion. However, we discovered a routing quirk: polling the standard v1 API with a UUID resulted in a 400 Bad Request: The Operation ID must be a Long. The v1 endpoint was strictly expecting numeric legacy IDs!

The Solution: We engineered a resilient fallback mechanism. We stripped the publisher paths from the operation name and routed the polling request to the experimental v1beta1 endpoint. Furthermore, we wrapped the polling loop in a "God Mode" safety net—if the Google routing API threw an exception, our Spring Boot service caught the HttpStatusCodeException, gracefully waited 40 seconds for the backend Veo rendering to finish, and successfully returned the Cloud Storage URL anyway. The architecture held strong.

Conclusion

Building Choragi pushed us to the limits of real-time streaming, asynchronous microservices, and multi-modal AI orchestration. By combining the infrastructure of Google Cloud with the intelligence of Gemini and Vertex AI, we successfully transformed the logistical chaos of event planning into an elegant, autonomous engine.

Artists should spend their time creating music that heals, not navigating ad campaigns and making cold calls. With AI orchestration, we can finally let them get back to the music.

Check out our full repository and project submission for the #GeminiLiveAgentChallenge!

From First Issue to Merged PR: My Journey Contributing to Spring AI

William — Sun, 19 Oct 2025 14:42:48 +0000

INTRODUCTION

For a long time, I admired open-source contributors from afar, people who helped build the libraries, frameworks, and tools that power the software we use daily. This October, during Hacktoberfest 2025, I decided to finally take the leap and make my first real contribution to open source.

That experience, contributing to Spring AI, a project under the Spring Framework turned out to be both challenging and rewarding. In this post, I’ll share what I did, what I learned, and why I think everyone should try contributing at least once.

How It Started

I joined Hacktoberfest this year with a simple goal: to understand what contributing to open source really feels like. After exploring a few repositories, I noticed Spring AI, an application framework for AI engineering built by the Spring team.

As someone interested in backend development, Java, and AI integrations, this felt like the perfect project to dive into. I scanned through open issues, read contribution guidelines, and picked an issue related to fixing Azure OpenAI auto-configuration.

The Contribution

The task was small but technical, updating a Spring Boot auto-configuration class to include the correct dependency for ToolCallingAutoConfiguration.

I forked the repository, cloned it locally, and followed the contribution setup. Along the way, I ran into:

Checkstyle formatting errors I didn’t cause but had to understand.
Build failures that taught me how Maven and Spring’s formatting rules work.
A review cycle with one of the project maintainers, who helped me refine the PR.

After I made the requested updates and pushed the final changes, the maintainer rebased, squashed, and merged my code into the project. Seeing my work appear in a widely used open-source framework was an incredible moment.

What I Learned

This single PR taught me a lot more than I expected:

Read contribution guides carefully, every project has its own workflow and formatting rules.
Code reviews are learning opportunities, maintainers often suggest small but important details that improve your engineering mindset.
Even small contributions matter, fixing a line of configuration or documentation still improves the project.
Communication is key. Be polite, thank reviewers, and show that you’re open to feedback.

It’s okay if your PR isn’t merged directly, sometimes maintainers rebase or squash your commits for consistency; what matters is that your work becomes part of the codebase.

The Hacktoberfest Twist

Although my pull request was part of Hacktoberfest, it wasn’t counted automatically because the maintainer rebased and merged it manually, a common workflow for large enterprise projects.

Still, the real reward wasn’t the t-shirt. It was seeing my name in the Spring AI commit history and knowing that I contributed to one of the world’s most recognized Java frameworks.

What’s Next

This first experience gave me confidence to keep contributing, not just during Hacktoberfest, but throughout the year. My goal now is to explore more open-source projects, particularly those involving:

Java and Spring Boot
AI integrations
Cloud and backend architecture

If you’re thinking about contributing but haven’t yet, start small. Fix a typo, improve documentation, or pick a “good first issue.” The open-source community is more welcoming than it looks.

Final Thoughts

Contributing to open source is one of the best ways to grow as a developer. It pushes you beyond tutorials into real-world collaboration, code quality, and communication.

I’m grateful to the Spring AI maintainers, especially @ilayaperumalg
, for their guidance and patience during my first PR review.

This experience reminded me that even the smallest contributions make a lasting impact, not only on the project but on your growth as a developer.

Pull Request: Fix Azure OpenAI Auto-Configuration – spring-projects/spring-ai#4636

Project: Spring AI GitHub Repository

Author: William Nnamani

hacktoberfest

Event-Driven Microservices with Apache Kafka And Spring Boot: A Practical Guide

William — Fri, 07 Feb 2025 18:39:37 +0000

Introduction

In modern microservices architecture, event-driven systems play a crucial role in enabling scalable, decoupled, and efficient communication between services. Apache Kafka has emerged as a leading distributed event-streaming platform, widely used for real-time data processing.

In this article, we will explore how to build an event-driven microservices system using Java Spring Boot and Apache Kafka, with a practical example of decoupling order processing from inventory management.

Why Event-Driven Microservices?

Traditional REST-based communication introduces tight coupling between services, making them harder to scale and maintain. Event-driven microservices solve this problem by allowing services to communicate asynchronously using events.

Benefits of Event-Driven Architecture:

Decoupling: Services interact via events, reducing direct dependencies.
Scalability: Independent services can scale as needed.
Resilience: Failures in one service do not immediately impact others.
Flexibility: Easily extend systems by adding new consumers.

Setting Up Apache Kafka

Before implementing our example, make sure you have Apache Kafka installed and running.

Download and Extract Kafka:

  Head over to this website [Download Apache Kafka](https://kafka.apache.org/downloads)
unzip to your favorite location
for this article i created a folder called software in local c on windows and rename kafka_2.13-3.0.0 to just kafka

Start Zookeeper and Kafka Broker:

    FOR ZOOKEEPER

   * To Start Zookeeper
   * open command prompt or terminal and CD into C:\softwares\kafka\bin\windows>
  * Then run this,  zookeeper-server-start.bat ..\..\config\zookeeper.properties 

FOR KAFKA BROKER 
  * To start kafka broker
  * open another command prompt or terminal and CD into C:\softwares\kafka\bin\windows>
  * Then run this, kafka-server-start.bat ..\..\config\server.properties

Experiment with Kafka

create a Topic - With another cmd instance open with same path you cd into to run both kafka broker and zookper while your kafka broker and zookeeper is still open, then run this command to create a kafka topic, kafka-topic.bat --bootstrap-server --create --topic order-topic --partitions 3 --replication-factor 1
- list Topic - run this command to list a kafka topic, kafka-topic.bat --bootstrap-server localhost:9092 --list
- describe a Topic - run this command to describe a kafka topic, kafka-topic.bat --bootstrap-server localhost:9092 --describe --topic order-topic
- publish message from producer to consumer - Open another instance of the command prompt and then run this to publish message from producer to consumer kafka-console-producer.bat --broker-list localhost:9092 --topic order-topic
- subscribe/consume message from producer - Open another instance of the command prompt and then run this to subscribe to message from the producer kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic order-topic --from-beginning

Implementing the Practical Example

Let's implement a scenario where an Order Service processes orders, and an Inventory Service listens to order events to update stock levels.

Create Spring Boot project

Head over to Spring Starter template
Create a Spring Boot Kafka Producer (Order Service)
add the dependency spring web and kafka

 <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

Create a Kafka Producer:

import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Service;

@Service
public class OrderProducer {
    private final KafkaTemplate<String, String> kafkaTemplate;

    public OrderProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void sendOrderEvent(String message) {
        kafkaTemplate.send("order-topic", message);
    }
}

Expose an API to trigger order processing:

import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/orders")
public class OrderController {
    private final OrderProducer orderProducer;

    public OrderController(OrderProducer orderProducer) {
        this.orderProducer = orderProducer;
    }

    @PostMapping("/create")
    public String createOrder(@RequestBody String orderDetails) {
        orderProducer.sendOrderEvent(orderDetails);
        return "Order event sent!";
    }
}

2. Create a Spring Boot Kafka Consumer (Inventory Service)

Create a Kafka Consumer:

import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.stereotype.Service;

@Service
public class InventoryConsumer {
    @KafkaListener(topics = "order-topic", groupId = "inventory-group")
    public void listenOrderEvents(ConsumerRecord<String, String> record) {
        System.out.println("Received Order Event: " + record.value());
        updateInventory(record.value());
    }

    private void updateInventory(String orderDetails) {
        // Simulate inventory update logic
        System.out.println("Inventory updated for order: " + orderDetails);
    }
}

Running the Application

Start Kafka and Zookeeper (if not already running).
Run the Order Service: Start the producer microservice.
Run the Inventory Service: Start the consumer microservice.
Trigger an Order Event:

   curl -X POST http://localhost:8080/orders/create -H "Content-Type: application/json" -d '"{"orderId": "123", "productId": "456", "quantity": "2"}"'

Check the Consumer Logs: You should see the order event being processed and the inventory updated.

Conclusion

Event-driven microservices with Apache Kafka provide a powerful way to build decoupled, scalable systems. In this guide, we demonstrated how to implement a simple order processing system using Kafka producers and consumers in Spring Boot.

By adopting event-driven design, you can create robust, loosely coupled microservices that scale efficiently while ensuring smooth communication between components.

Please if you find the article interesting and valuable drop a like and comment. See you in the next one, keep building!
Follow me on socials my Linkedin Handle

How to Design a Scalable Microservices Architecture: Lessons from Real-World Systems

William — Fri, 07 Feb 2025 12:42:36 +0000

Introduction

Microservices architecture has become the poster child of modern software development. It promises scalability, flexibility, and the dream of independent deployability. But let’s be real—building a microservices-based system isn’t all sunshine and rainbows. It comes with its own set of challenges, especially when working with Java and Spring Boot.

In this article, we’ll dive into real-world lessons learned from implementing microservices.

Lesson 1: Microservices Doesn’t Mean Micro-Problems

Many teams start with microservices thinking, "Let’s break this monolith into smaller, manageable pieces." Sounds great, right? Until you realize you now have 20+ services talking to each other like a whole community fetching from a stagnant stream of water.

Solution: Proper Service Boundaries

Use Domain-Driven Design (DDD) to define proper service boundaries.
Avoid creating microservices that are too micro—sometimes a monolith is just a misunderstood hero.
Ensure each service has a clear, independent responsibility.

Lesson 2: Distributed Transactions Are a Nightmare

In monolithic applications, transactions are simple—you start one, do some operations, commit or rollback. But in microservices? Welcome to the Saga pattern and compensating transactions, where a failed step means you have to undo everything.

Solution: Handling Transactions Properly

Use the Saga pattern for long-running transactions.
Implement event-driven architectures with tools like Kafka or RabbitMQ.
Idempotency is your best friend—ensure your services can handle duplicate requests gracefully.

Lesson 3: Latency is the Silent Killer

Breaking down a monolith into microservices means your once-simple function call is now a network request. And we all know how reliable networks are. Suddenly, your ultra-fast system is moving at the speed of a sloth on a Monday morning.

Solution: Performance Optimization

Use circuit breakers (Resilience4j, Hystrix) to prevent cascading failures.
Implement caching (Redis, EhCache) to avoid unnecessary calls.
Monitor API latencies and optimize slow endpoints.

Lesson 4: Versioning is Inevitable

Deploying updates in a microservices world can be like trying to replace a car tire while speeding down the highway. One breaking change, and everything falls apart.

Solution: Backward-Compatible APIs

Use semantic versioning (e.g., v1, v2 endpoints).
Follow API-first design with OpenAPI and Swagger.

Lesson 5: Logging and Monitoring Save Lives

Debugging a microservices system without proper logging is like trying to solve a crime without evidence. You think you know what’s happening, but reality is a different story.

Solution: Observability Tools

Centralize logs using ELK Stack (Elasticsearch, Logstash, Kibana) or Grafana Loki.
Implement distributed tracing with Jaeger or Zipkin.
Monitor metrics with Prometheus and Grafana.

Lesson 6: Security is Not Optional

Exposing multiple microservices to the world without security is like leaving your house with the doors open and a sign that says, "Come on in, free valuables inside!"

Solution: Secure Your Services

Use OAuth 2.0 and JWT for authentication.
Implement API gateways (Spring Cloud Gateway) for centralized security.
Keep dependencies up to date to avoid vulnerabilities.

Conclusion

Microservices architecture, when done right, can bring immense benefits. But it requires careful planning, solid design principles, and the right set of tools. Java and Spring Boot provide a robust ecosystem to build scalable and resilient microservices, but they also come with challenges that need to be addressed.

So, before you jump headfirst into microservices, ask yourself: "Do I really need this, or can my monolith still do the job?" Because sometimes, the best microservice decision is not using microservices at all!

Please like this post and comment if you find it valuable and interesting, till next time keep building.
You can connect with me on socials: My Linkedin Handle