SaaS crédito facturación directamente modificar saldo columna es rápido pero peligroso. Hashscraper registra todas las deducciones como historial (libro mayor) y calcula el saldo como la suma del historial, utilizando una arquitectura de facturación basada en el libro mayor. Este enfoque es beneficioso en transparencia de facturación, facilidad de depuración y rendimiento de procesamiento masivo simultáneo.
TL;DR
- Modificar directamente (ACTUALIZAR) el saldo es rápido, pero no se puede rastrear la causa de los errores.
- Registrar todas las deducciones como historial (libro mayor) permite demostrar todas las transacciones.
- El bloqueo de fila (SELECT FOR UPDATE) se convierte en un cuello de botella en solicitudes simultáneas. No hay cuellos de botella con la inserción en el libro mayor.
- Hashscraper procesa decenas de miles de transacciones al día, el enfoque del libro mayor supera en velocidad y precisión.
- La arquitectura de facturación es un compromiso con los clientes, no solo ingeniería.
¿Por qué la mayoría de los SaaS modifican el saldo directamente?
Cuando se deduce crédito, la mayoría de los SaaS hacen lo siguiente.
Abren la columna de saldo, restan un número y guardan.
UPDATE service_tickets SET use_credit = use_credit + 10 WHERE id = ?
Es rápido.
Es intuitivo.
Casi todos los tutoriales de facturación enseñan este método.
Al principio, también lo hicimos nosotros.
¿Qué se pierde al solo ver el saldo?
Cuando surge un problema en producción,
no teníamos dónde buscar.
"¿Por qué a este cliente le faltan 3 créditos?"
"¿Se dedujeron en la solicitud fallida de ayer o no?"
"¿Cómo verificamos si este número es correcto?"
El saldo solo muestra el resultado.
El proceso desaparece.
Es como un libro de contabilidad escrito a lápiz.
Si lo borras y vuelves a escribir, no sabes qué estaba escrito originalmente.
¿Qué es la facturación basada en el libro mayor?
Por eso cambiamos el enfoque.
No modificamos el saldo directamente.
Registramos todas las deducciones en un registro de historial separado.
El saldo se calcula como la suma del historial.
이력 #1: -10 크레딧 (https://example.com, 성공, 2026-03-07 14:32)
이력 #2: -10 크레딧 (https://news.site.com, 성공, 2026-03-07 14:33)
이력 #3: 0 크레딧 (https://blocked.com, 실패, 2026-03-07 14:35)
─────────────────
잔액 = 총 크레딧 - 이력 합산
Es como un libro de contabilidad de doble entrada escrito con bolígrafo.
Cuando se modifica, se tacha y se escribe en una nueva línea.
Ninguna transacción desaparece.
Cada deducción tiene un registro adjunto.
Cuándo, qué URL, cuántos créditos, éxito o fracaso.
No se deducen las solicitudes fallidas.
Si se deducen, siempre hay una razón registrada.
¿Por qué el enfoque del libro mayor es más rápido para el procesamiento masivo?
Aquí surge la pregunta.
"¿No es lento insertar historial cada vez?"
Hashscraper ha estado recopilando datos de más de 5,000 sitios web durante 8 años desde 2018.
Procesa decenas de miles de solicitudes al día.
No podemos sacrificar la velocidad.
Sin embargo, paradójicamente,
el enfoque del libro mayor es más rápido.
Para modificar el saldo directamente se necesita un bloqueo de fila (SELECT FOR UPDATE).
Si llegan 10 solicitudes simultáneas del mismo cliente,
9 deben esperar en fila.
Es como un oficial de tráfico dejando pasar un auto a la vez.
El enfoque de registro es diferente.
La inserción no bloquea otras filas.
Si llegan 10 solicitudes simultáneas, las 10 se registran de inmediato.
Es como una autopista de 10 carriles.
El saldo se suma más tarde.
| Método | Procesamiento simultáneo de 10 | Cuello de botella | Rastreo de fallos |
|---|---|---|---|
| Modificación directa del saldo (bloqueo de fila) | Procesamiento secuencial (1 a la vez) | Grave | Imposible |
| Registro en el libro mayor (INSERCIÓN) | Procesamiento en paralelo (10 simultáneos) | Ninguno | Rastreo inmediato mediante historial |
El método que parece más lento
en realidad no tiene cuellos de botella en el procesamiento masivo.
¿Por qué la arquitectura de facturación es un compromiso con los clientes?
Esto no es una cuestión de preferencia de ingeniería.
La arquitectura de facturación es en última instancia la respuesta a esta pregunta:
- ¿Puede responder inmediatamente cuando un cliente pregunta "¿Dónde están mis créditos?"
- ¿Puede encontrar exactamente dónde se equivocó si se dedujo incorrectamente debido a un error del sistema?
- ¿Puede demostrar que no se facturó por una solicitud fallida?
Una sola columna de saldo no puede responder a esta pregunta.
Se necesita un historial para responder.
Somos una pequeña empresa de 4 personas.
No podemos permitirnos hacer las cosas a medias debido a nuestro tamaño,
debemos hacerlas correctamente debido a nuestro tamaño.
Poder mostrar en cualquier momento en qué se gastó un crédito del cliente.
Esa es la razón por la que elegimos el bolígrafo para el sistema de facturación.
No reduzcas el saldo. Permite que el historial cree el saldo.
Preguntas frecuentes
P. ¿No es lenta la consulta de saldo con el enfoque del libro mayor?
El saldo se calcula como la suma del historial, pero no se calcula en tiempo real cada vez. No afecta al rendimiento de la consulta si se almacena en caché periódicamente o se liquida posteriormente. Incluso con decenas de miles de registros de historial, el cálculo basado en índices toma solo milisegundos.
P. ¿Se registra el historial incluso para solicitudes fallidas?
Sí. Se registra el historial de fallos, pero el monto deducido es 0. El hecho de "esta solicitud falló y no se facturó" es la base de la confianza del cliente.
P. ¿Hay casos en los que el enfoque de bloqueo de fila es adecuado?
En servicios de pequeña escala con pocas solicitudes simultáneas, el bloqueo de fila es más simple y efectivo. Sin embargo, en estructuras con solicitudes simultáneas frecuentes como la facturación de API, el enfoque del libro mayor es superior en rendimiento y rastreabilidad.
P. ¿Cuál es la unidad de facturación de Hashscraper?
1 solicitud de URL = 10 créditos y solo se deducen si la recopilación y conversión son exitosas. No hay pérdida de créditos en caso de fallo.
