Architektura rozmów AI w Salesforce – lekcja dla praktyka

Przy 30 tys. zdarzeń na minutę samo dołożenie streamingu nie rozwiązuje problemu skali – może za to wprowadzić opóźnienia, które psują pracę agentów i systemów AI.

To ma znaczenie teraz, bo conversational AI w Service Cloud przestaje być dodatkiem do case management i staje się warstwą operacyjną dla agentów, supervisorów oraz automatyzacji (Salesforce Engineering). Gdy liczba równoległych konwersacji rośnie z 10 tys. do 50 tys. i docelowo do 100 tys., największym problemem nie jest już samo zapisanie wiadomości, ale utrzymanie spójnego, prawie natychmiastowego kontekstu. Dla architekta, admina i dewelopera to ważna wskazówka – przy workloadach AI trzeba projektować nie tylko throughput, ale też widoczność danych tuż po zapisie.

Od transakcyjnego storage do architektury rozproszonej

Conversation Storage Service pełni rolę systemu prawdy dla kontekstu rozmów w kanałach cyfrowych. Na tych danych opierają się funkcje czasu rzeczywistego, takie jak analiza sentymentu, agent assist i insighty dla supervisorów. Taki model działał poprawnie przy około 10 tys. równoległych konwersacji, kiedy transakcyjny system oparty o Postgres wystarczał do obsługi zapisu i odczytu.

Problemy pojawiły się wraz z nierównym ruchem generowanym przez tenantów o wysokiej aktywności. Bursty traffic tworzył hotspoty i obniżał wydajność zapisów w całej platformie. Sam wzrost wolumenu nie był jedynym wyzwaniem – rozmowy stawały się dłuższe, payloady większe, a do tego dochodziły nowe formaty, jak transkrypcje głosowe, e-maile konwersacyjne i odpowiedzi generowane przez AI.

Odpowiedzią było przejście do horyzontalnie skalowanej bazy No-SQL oraz przeniesienie części buforowania i batchingu do warstwy aplikacyjnej na poziomie tenanta. To ogranicza wpływ skoków ruchu na storage, ale nie usuwa problemu nierównowagi całkowicie. Dlatego kolejnym krokiem stał się Kafka z partycjonowaniem na poziomie konwersacji, który rozkłada obciążenie i wygładza piki zanim trafią do trwałego zapisu.

Dla praktyka Salesforce wniosek jest prosty: jeśli architektura ma zasilać agentów AI, nie wystarczy myśleć kategoriami CRUD i klasycznej skali obiektów. Trzeba rozdzielić warstwę ingestu, warstwę utrwalania i warstwę dostępu do świeżych danych. To dobrze koresponduje z kierunkiem API-first i headless, który widać też w analizie Headless 360 dla architektów, gdzie interfejs przestaje być centrum systemu, a kluczowe stają się przepływy danych i ich kontrola.

Najtrudniejszy problem: read-after-write consistency

Streaming ustabilizował ingest, ale wprowadził nowy koszt – asynchroniczność. Gdy zapis trafia do pipeline’u, odczyt może przez chwilę nie widzieć najnowszego stanu. W praktyce to klasyczna luka read-after-write, szczególnie groźna w service, gdzie agent lub model AI musi reagować na ostatnią wiadomość klienta bez czekania na pełne dogonienie kolejki.

Przy skali powyżej 30 tys. zdarzeń na minutę głównym ograniczeniem stał się consumer lag w Kafka. Pod dużym obciążeniem zdarzenia trafiały do kolejek, co opóźniało zapis danych i tworzyło luki w dostępie do informacji. To nie jest detal infrastrukturalny, tylko problem produktowy – agent może nie zobaczyć świeżej odpowiedzi, a system AI może policzyć insight na niepełnym kontekście.

Rozwiązaniem stał się VegaCache, który udostępnia ostatnie zapisy bezpośrednio z pamięci, zanim trwała persystencja nadrobi opóźnienie. W ten sposób warstwa cache maskuje opóźnienia streamingu i przywraca praktyczną spójność odczytu tuż po zapisie. Dodatkowo pomagają conversation partitioning, batching i back-pressure controls, które redukują hotspoty i stabilizują przepływ.

To cenna lekcja także dla zespołów budujących orkiestrację AI poza samym Service Cloud. Samo dodanie kolejki nie gwarantuje przewidywalności, jeśli nie ma mechanizmu priorytetyzacji i szybkiego dostępu do świeżego stanu. Podobny wzorzec widać w analizie persistent queue dla workloadów Agentforce, gdzie ograniczenia przepustowości wymuszają świadome sterowanie ruchem, a nie tylko jego buforowanie.

Z perspektywy architekta warto więc zadawać trzy pytania: gdzie powstaje źródło prawdy, jak długo trwa rozjazd między zapisem a odczytem i która warstwa maskuje ten rozjazd dla użytkownika lub agenta AI. Bez tych odpowiedzi nawet dobrze skalujący się pipeline może zawieść w scenariuszach czasu rzeczywistego.

Skala 100 tys. rozmów wymaga myślenia o danych jak o produkcie

Droga do 100 tys. równoległych konwersacji nie sprowadza się do zwiększenia mocy storage. CSS zmienia się w warstwę dystrybucji danych dla wielu odbiorców jednocześnie – operacyjnych, analitycznych i AI. Dane z rozmów muszą trafiać do Data 360, raportowania Core oraz pipeline’ów AI, mimo że każdy z tych odbiorców pracuje na innych formatach i oczekuje innego modelu danych.

Tu pojawia się kolejny limit: ręczne mapowanie schematów i definiowanie obiektów dla każdego typu interakcji spowalnia integrację. Odpowiedzią ma być metadata-driven integration layer, która upraszcza dodawanie nowych typów danych i ogranicza ręczną pracę wokół schematów. Równolegle CSS wspiera bulk export przez S3 dla analityki na dużą skalę.

To ważny sygnał dla polskich zespołów pracujących z Data Cloud, Service Cloud i Agentforce. Jeśli conversational AI ma działać szerzej niż pojedynczy use case, model danych nie może być traktowany jako efekt uboczny implementacji kanału. Musi być projektowany jako kontrakt dla wielu konsumentów – od agentów, przez raportowanie, po automatyzacje i modele. W praktyce oznacza to większy nacisk na jakość danych, typy interakcji i governance, podobnie jak w podejściu opisanym w tekście o przygotowaniu danych Salesforce pod AI.

Planowany kierunek curated Kafka sugeruje jeszcze jedną zmianę: stream ma stać się uporządkowanym źródłem prawdy, co zmniejszy zależność od wielu równoległych źródeł. Dla architektury oznacza to przesunięcie z modelu storage-first do stream-first, ale tylko pod warunkiem utrzymania porządku zdarzeń i szybkiej widoczności najnowszego stanu.

Najważniejszy wniosek jest praktyczny. Przy systemach rozmów napędzanych AI skala nie kończy się na liczbie wiadomości. Liczy się jednocześnie kolejność, świeżość, rozmiar payloadu i możliwość bezpiecznego podania tych danych wielu usługom naraz. To właśnie ten zestaw wymagań zaczyna dziś definiować nową architekturę service na platformie Salesforce.

Rosnąca liczba konwersacji AI pokazuje, że największe ryzyko nie leży w samym storage, ale w luce między ingestem, odczytem i integracją danych. Dobrze zaprojektowana architektura musi łączyć rozproszony zapis, streaming, cache dla świeżych danych i warstwę integracyjną opartą o metadata. Pytanie dla zespołów wdrożeniowych brzmi więc nie czy obsłużycie większy wolumen, ale czy wasz org potrafi utrzymać spójny kontekst rozmowy w chwili, gdy potrzebuje go człowiek lub agent AI.