Més enllà dels límits de taxa: escalar l’accés a Codex i Sora

Durant l’últim any, tant Codex com Sora han vist una adopció ràpida, i l’ús ha superat de pressa el que esperàvem inicialment. Hem vist un patró constant: els usuaris s’hi endinsen, hi troben un valor real i després topen amb els límits de taxa.

Els límits de taxa poden ajudar a suavitzar la demanda i garantir un accés just; tanmateix, quan els usuaris n’obtenen valor, topar amb un tall brusc pot ser frustrant. Volíem una manera perquè els usuaris poguessin continuar, alhora que protegíem el rendiment del sistema i la confiança dels usuaris en el nostre enfocament.

Per resoldre-ho, vam construir un motor d’accés en temps real que compta l’ús. Una de les capes d’aquest motor és la capacitat de comprar crèdits. Quan els usuaris superen els seus límits de taxa, els crèdits els permeten continuar utilitzant els nostres productes consumint el seu saldo de crèdit.

A sota hi ha un sistema complex que fusiona límits, seguiment d’ús en temps real i saldos de crèdit en un únic model d’accés. Aquesta entrada explica per què escalar Codex i Sora va requerir repensar el control d’accés, com un sistema demostrablement correcte i en temps real combina límits de taxa i crèdits per petició, i com aquesta base ara desbloqueja accés addicional per a tots dos productes.

Si fem una mirada general, els models d’accés tradicionals tendeixen a forçar una elecció:

• Els límits de taxa poden ser útils al principi, però deixen els usuaris amb una mala experiència quan s’esgoten: «torna més tard»
• La facturació basada en l’ús és flexible, però fa que els usuaris paguin des del primer segment—no és ideal per donar suport a l’exploració inicial

Per a Codex i Sora, cap dels dos no era suficient per si sol. Si simplement augmentéssim els límits de taxa, perdríem controls importants de suavització de la demanda i d’equitat, i ens quedaríem sense capacitat per atendre tothom. Si depenguéssim del tot de la facturació d’ús asíncrona, introduiríem retard, sobrecàrrecs o problemes de conciliació—justament el tipus de problemes que els usuaris noten quan estan més implicats.

El que necessitàvem, en canvi, era un únic sistema híbrid que combinés límits en temps real amb accés de pagament per ús:

Aquest sistema havia de:

• Aplicar límits de taxa fins que s’assoleixin
• Passar sense friccions als crèdits dins de la mateixa petició
• Prendre aquesta decisió en temps real
• Ser rigorosament precís i auditable en el seguiment del consum de crèdit

Un dels canvis conceptuals clau que vam fer va ser modelar l’accés com una cascada de decisions. En lloc de preguntar «això està permès?», preguntem «quant està permès, i d’on?». Quan compta l’ús, el sistema segueix la seqüència següent:

Aquest model reflecteix com els usuaris realment experimenten el producte. Els límits de taxa, els nivells gratuïts, els crèdits, les promocions i els drets d’empresa són només capes dins de la mateixa pila de decisions. Des de la perspectiva de l’usuari, no «canvien de sistema», simplement continuen utilitzant Codex i Sora. Per això els crèdits semblen invisibles: són només un altre element de la cascada.

Vam avaluar plataformes de tercers de facturació i mesurament d’ús per gestionar el consum de crèdit. Són adequades per a facturació i informes, però no complien dos requisits crítics:

Quan un usuari arriba a un límit i té crèdits disponibles, el sistema ho ha de saber immediatament. Un recompte basat en el millor esforç o retardat es tradueix en bloquejos inesperats, saldos incoherents i càrrecs incorrectes. En productes interactius com Codex i Sora, aquests errors es fan visibles i resulten frustrants.

També necessitàvem oferir transparència sobre cada resultat:

• Per què es va permetre o bloquejar una petició
• Quant d’ús va consumir
• Quins límits o saldos es van aplicar

Aquesta capacitat havia d’estar estretament integrada en la nostra cascada de decisions i no resolta de manera aïllada en una plataforma separada de facturació d’ús que només veiés una part del que estava passant. Per permetre que els usuaris accedissin als nostres productes sense comprometre la confiança, necessitàvem control total sobre la correcció, el temps i l’observabilitat. Això ens va empènyer cap a una solució interna.

Per fer-ho possible, vam construir un sistema distribuït d’ús i saldos dissenyat específicament per a decisions d’accés síncrones.

A grans trets, el sistema:

• Fa seguiment de l’ús per usuari i per funcionalitat
• Manté finestres de límit de taxa
• Manté saldos de crèdit en temps real
• Carrega els saldos de manera idempotent mitjançant un processador asíncron en streaming

Cada petició passa per un únic camí d’avaluació que pren una decisió en temps real sobre quina quantitat d’ús està permesa consumint de manera síncrona els límits de taxa i, si cal, verificant que hi hagi prou crèdits; després retorna un únic resultat definitiu mentre liquida qualsevol càrrec de crèdit de manera asíncrona. Això garanteix un comportament coherent entre productes i elimina la lògica duplicada entre equips.

Un dels principis clau de disseny d’aquest sistema és que hem de poder demostrar que la nostra facturació és correcta. Això reflecteix els orígens del nostre suport de crèdit, que es va originar amb clients empresarials. Al diagrama del sistema anterior, tenim tres conjunts de dades separats que estan tots connectats:

• Esdeveniments d’ús del producte: El que l’usuari va fer realment
• Esdeveniments de monetització: El que cobrem a l’usuari pel seu ús
• Actualitzacions de saldo: Quant vam ajustar el saldo de crèdit de l’usuari i per què

Aquests conjunts de dades no són un subproducte casual; de fet, impulsen el sistema, amb cada conjunt de dades activant el següent. Separar el que ha passat, els càrrecs associats i el que hem carregat ens permet auditar, reproduir i conciliar de manera independent cada capa. Aquest és un compromís intencionat en què prioritzem la correcció demostrable, al cost que les actualitzacions del saldo de crèdit es retardin lleugerament. Com ho vam aconseguir:

• Els esdeveniments d’ús del producte es publiquen per a tota l’activitat de l’usuari, tant si impulsa el consum de crèdit com si no. Això proporciona un rastre d’auditoria de l’activitat de l’usuari i ens permet explicar per què vam cobrar, o no vam cobrar, crèdits.
• Cada esdeveniment porta una clau d’idempotència estable, de manera que els reintents, les repeticions o els reinicis de worker mai no poden carregar dues vegades un saldo, cosa que evita el doble cobrament. Això també ens permet executar una conciliació per lots per verificar la nostra feina fora de línia.
• Fem actualitzacions de saldo asíncrones (però encara gairebé en temps real) en lloc d’actualitzacions síncrones per crear un rastre d’auditoria. Tolerem un petit retard en actualitzar el saldo de l’usuari perquè puguem demostrar que el sistema funciona i assegurar als nostres usuaris que no els facturem incorrectament. Quan aquest breu retard fa que superem el saldo de crèdit d’un usuari, el reemborsem automàticament; triem la correcció demostrable i la confiança de l’usuari per damunt de l’aplicació estricta.
• Disminuïm el Saldo de crèdit i inserim un registre d’Actualització de saldo en una sola transacció atòmica de base de dades. Les actualitzacions de saldo se serialitzen per compte, de manera que les peticions concurrents mai no poden competir per gastar els mateixos crèdits. El registre d’Actualització de saldo conté tant l’import del càrrec com l’atribució a l’esdeveniment de monetització que va activar l’actualització; encapsular això en una sola transacció de base de dades garanteix que tinguem un rastre d’auditoria per a cada ajust del saldo de crèdit.

Tot aquest rigor dona suport a un objectiu: fer que l’accés sigui simple i segur. Quan la gent crea o programa, no hauria de preguntar-se si una petició tirarà endavant, si se’ls cobrarà de més o si el seu saldo és correcte. En fer que l’ús, la facturació i els saldos siguin demostrablement correctes, oferim als usuaris un sistema que no distreu de la seva experiència. Això és el que ens permet substituir els talls bruscos per accés continu—i és el que fa que els crèdits siguin útils enmig de feina real, no només en una factura.

El principi rector del nostre enfocament és protegir l’impuls de l’usuari. Cada decisió arquitectònica es correspon amb un resultat orientat a l’usuari: els saldos en temps real eviten interrupcions innecessàries, el consum atòmic evita el doble cobrament i la lògica d’accés unificada garanteix un comportament previsible. El resultat és que la gent pot treballar més estona, explorar amb més profunditat i portar els projectes més lluny sense topar amb talls bruscos ni canvis prematurs de pla.

Quan els usuaris estan implicats, el sistema els ha d’ajudar a continuar, no posar-se pel mig. Els límits i els crèdits desapareixen en segon pla.

Construir aquesta experiència va requerir repensar l’accés, l’ús i la facturació com un únic sistema i construir una infraestructura que tracti la correcció com una funcionalitat de producte de primer nivell. La mateixa base es pot estendre a més productes amb el temps; Codex i Sora només són el començament.