het ontwerpen van een serverloze ai-gestuurde multi-domein cms op google cloud

het fundamentele conflict waarmee ik te maken kreeg, was de aard van contentgeneratie versus contentconsumptie. ai-gestuurde artikelgeneratie omvat een complexe reeks bewerkingen: real-time webonderzoek, opstellen met grote taalmodellen, het maken van afbeeldingen met diffusiemodellen en meertalige vertaling. dit hele proces is intrinsiek i/o-gebonden en cpu-intensief, en duurt vaak meerdere minuten. mijn ontwerp moest dit 'zware werk' volledig scheiden van de eindgebruikerservaring. lezers verwachten dat statische webpagina's in enkele milliseconden worden geladen, geserveerd vanaf een edge-locatie dicht bij hen.

dit leidde me tot de implementatie van een hybride model: dynamische generatie voor auteurs en redacteuren, en statische, in de edge gecacheerde levering voor lezers. de ai-pipeline is asynchroon en losgekoppeld, en pusht gefinaliseerde inhoud naar een snelle leveringslaag. dit zorgt ervoor dat het rekenkundig dure ai-werk nooit de gebruikersgerichte latentie beïnvloedt.

mijn keuze voor de computelaag was google cloud run. ik vond het een krachtig, volledig beheerd serverloos platform waarmee ik gecontaineriseerde applicaties kon implementeren die automatisch schalen van nul naar duizenden instanties. dit betekende dat ik alleen betaalde voor de gebruikte rekenkracht, wat perfect aansluit bij onze finops-doelen. voor mij is de schoonheid van cloud run de eenvoud in het implementeren van microservices zonder de onderliggende infrastructuur te beheren.

het cms zelf draait als verschillende afzonderlijke cloud run-services, die elk een specifiek deel van het systeem afhandelen:

• backend (backend-svc-prod): een fastapi rest api-service die de kerncontentpijplijnen afhandelt, webhooks opneemt en asynchrone taakuitvoering beheert. hier bevindt zich de ai-orkestratielogica.
• frontend (frontend-admin-svc-prod): een nicegui-gebaseerde administratieve interface. hiermee kan mijn team ai-contentgeneratie controleren, beoordelen en handmatig activeren, waardoor we gedetailleerde controle hebben over het redactionele proces.
• documentatieserver (mcp-docs-svc-prod): een model context protocol (mcp)-server. ik heb deze gebouwd om contextophaling voor de backend te bieden, en fungeert in wezen als een retrieval augmented generation (rag)-service voor onze ai-modellen, door ze up-to-date, relevante marktinformatie te voeden.

door deze componenten te verpakken als gecontaineriseerde microservices vanuit één docker-image, zorgde ik voor consistentie tussen omgevingen en vereenvoudigde ik onze implementatieworkflows aanzienlijk.

de belangrijkste technische uitdaging die ik tegenkwam, was het beheren van uitvoeringstime-outs. een volledige artikelgeneratiepipeline kan gemakkelijk de typische synchrone request timeout van een webservice overschrijden (bijvoorbeeld, cloud run heeft een maximale request timeout van 900 seconden). om dit te omzeilen, implementeerde ik een asynchrone, gebeurtenisgestuurde pipeline met behulp van cloud scheduler en google cloud pub/sub.

dit patroon stelde me in staat om de workload te splitsen in een snelle, synchrone trigger en een ontkoppelde, asynchrone verwerkingsfase. cloud scheduler fungeert als een tijdgebaseerde trigger en stuurt een geauthenticeerd verzoek naar onze backend met vooraf gedefinieerde intervallen. de backend initieert snel het opstellen van inhoud, persisteert de status en publiceert vervolgens een bericht naar een pub/sub-onderwerp. hierdoor kan de initiële aanvraag snel worden voltooid, waardoor de frontend of scheduler vrijkomt.

pub/sub levert dit bericht vervolgens betrouwbaar aan een andere instantie van onze backend-service (geconfigureerd als een push-abonnement), die de langlopende taken afhandelt, zoals het ophalen van onderzoek, het genereren van afbeeldingen en het vertalen van inhoud. dit lost niet alleen het time-outprobleem op, maar biedt ook een veerkrachtige en schaalbare manier om onze contentgeneratietaken te verwerken.

voor openbare contentlevering worden de statische html, css en afbeeldingen die door de ai-pipeline zijn gegenereerd, rechtstreeks naar google cloud storage (gcs)-buckets geschreven. ik configureerde een global external application load balancer om openbaar verkeer (/*) rechtstreeks naar deze gcs-backend te routeren. cruciaal is dat cloud cdn deze inhoud wereldwijd cachet, waardoor een latentie van enkele milliseconden wordt gegarandeerd voor eindgebruikers, ongeacht hun geografische locatie. dit ontwerp ontkoppelt de dynamische ai-verwerking volledig van contentlevering, waardoor effectief aan onze vereiste voor lage latentie wordt voldaan.

voor administratieve toegang tot het cms implementeerde ik een zero-trust-model met behulp van identity-aware proxy (iap). administratieve eindpunten (bijv. admin.thecloudarchitect.io) delen dezelfde load balancer, maar routeren verkeer naar de cloud run serverloze network endpoint groups (negs). voordat een verzoek de cloud run-service bereikt, onderschept iap dit, waarbij google-accountauthenticatie en gedetailleerde iam-beleidsregels worden afgedwongen. dit biedt een robuuste beveiligingsperimeter, waardoor het aanvalsoppervlak aanzienlijk wordt verkleind. om gevoelige referenties, zoals api-sleutels voor gemini of tavily, te beschermen, sla ik ze veilig op in secret manager en injecteer ik ze in de cloud run-services tijdens runtime, waardoor onze beveiligingspositie verder wordt verbeterd.

architecturaal overzicht

ik heb het cms zo gebouwd dat ai niet slechts als een eenvoudige api-aanroep wordt behandeld, maar als een geavanceerde meerfasenworkflow, allemaal georkestreerd binnen de cloudrunbackend-service. dit stelde me in staat om complexe artikelgeneratie op te splitsen in beheersbare, observeerbare stappen:

1. gegevensinvoer & aarding: ten eerste injecteer ik relevante marktgegevens (bijv. topstijgers/dalers, ochlv-gegevens) in het contextvenster van de prompt. deze gegevens zijn doorgaans afkomstig van onze interne ta-api of een speciale marktdatenservice, en bieden real-time, accurate informatie waarmee de ai kan werken.
2. onderzoek (tavily): afhankelijk van het artikeltype configureerde ik het systeem om 1 tot 10 tavily api-aanroepen te doen. voor een 'sector spotlight' helpt dit bijvoorbeeld om real-time katalysatoren, overnight news of specifieke bedrijfsaankondigingen op te halen, zodat de ai-modellen over de meest actuele externe informatie beschikken.
3. schrijver (gemini 2.5 flash): ik gebruik een initiële promptsjabloon (meestal op basis van jinja2) om gemini 2.5 flash te sturen om de ruwe json-payload van het artikel op te stellen. gemini 2.5 flash biedt een uitstekende balans tussen prestaties en kostenefficiëntie, waardoor het ideaal is voor het snel en betaalbaar genereren van initiële concepten.
4. editor (gemini 2.5 pro): zodra het concept is voltooid, beoordeelt een sterker, capabeler model, gemini 2.5 pro, het. deze kritieke stap controleert de toon, nauwkeurigheid, feitelijke consistentie en juiste opmaak. deze multi-modelaanpak stelt me in staat om de specifieke sterke punten van elk model te benutten en tegelijkertijd de totale kosten te optimaliseren.
5. visuals (imagen 3): tijdens het opstellen genereert gemini 2.5 flash ook duidelijke, beschrijvende prompts voor visuele assets – meestal een 16:9 hero-afbeelding en een 1:1 ondersteunende afbeelding. deze prompts worden vervolgens gevoed aan imagen 3, google's geavanceerde tekst-naar-afbeelding diffusiemodel, om hoogwaardige visuals voor het artikel te genereren.
6. vertaling: ten slotte wordt de engelse tekst teruggegeven aan gemini (flash of pro, afhankelijk van de vereiste kwaliteit-kostenafweging voor vertaling) voor lokalisatie in doeltalen zoals duits (de), spaans (es), frans (fr), italiaans (it) en nederlands (nl). deze vertaalde versies maken ook deel uit van de statische inhoud die via cloud cdn wordt geleverd.

het draaien van grote taalmodellen en wereldwijde cloudinfrastructuur kan snel kostbaar worden als het niet zorgvuldig wordt beheerd. mijn architectuur maakt gebruik van strikte finops-controles om de efficiëntie te handhaven, zodat we maximale waarde krijgen voor onze uitgaven.

6.1. eenheidseconomie van een ai-artikel

door modellen zorgvuldig te selecteren en api-aanroepen te optimaliseren, heb ik de kosten per artikel uitzonderlijk laag kunnen houden. het gebruik van gemini 2.5 flash voor grootschalige concepten en prompt engineering, en het reserveren van gemini 2.5 pro alleen voor de kritieke redactionele controle, heeft een aanzienlijke invloed op de totale kosten. hier is een overzicht op basis van de huidige prijzen (ongeveer $1 ≈ €0,92):

• tavily (onderzoek): typisch ~€0,02 – €0,07 (~$0,02 – $0,08) per artikel, afhankelijk van het aantal zoekopdrachten.
• gemini (schrijver/editor/prompts/vertalingen): ongeveer ~€0,05 (~$0,055) voor alle gemini-interacties.
• imagen (2 afbeeldingen): het genereren van twee afbeeldingen met hoge resolutie kost ~€0,05 – €0,07 (~$0,06 – $0,08).
• totale kosten per volledig gepubliceerd, meertalig artikel: ~€0,13 – €0,15 (~$0,14 – $0,16).

dit toont de kracht aan van een fijn afgestemde ai-pipeline bij het bereiken van opmerkelijke kostenefficiëntie.

6.2. schaal-naar-nul en mitigatie van koude start

het vermogen van cloud run om naar nul instanties te schalen wanneer het inactief is, is een enorme finops-winst, waardoor de rekenkosten aanzienlijk worden verlaagd buiten de piekuren. dit introduceert echter het potentieel voor koude starts (doorgaans 5-15 seconden latentie) voor gebruikersgerichte services, met name onze admin-frontend of intraday api-triggers. om dit te verzachten zonder continue kosten te maken van altijd actieve instanties, heb ik een speciale cloud scheduler 'keep-warm'-taak geïmplementeerd.

deze taak pingt zowel de backend (/health?deep=true) als de frontend (/health) elke 14 minuten, strikt tijdens europese kantooruren (06:00 – 22:00 cet). dit zorgt ervoor dat tijdens onze operationele uren, kritieke services warm en responsief zijn, terwijl ze 's nachts en in het weekend nog steeds naar nul kunnen schalen, waardoor de kostenbesparingen worden gemaximaliseerd.