Enunciado y contexto
Un servicio de pedidos debe crear un pedido, decrementar el inventario y escribir una entrada en el libro contable en una sola operación de negocio. Puede ocurrir un tiempo de espera de red después de que DynamoDB confirme, por lo que el cliente puede enviar la solicitud nuevamente. Utilice TransactWriteItems para diseñar escrituras atómicas, condiciones, reintentos idempotentes y reconciliación, incluyendo el costo de capacidad y los límites regionales.
Qué evalúa el entrevistador
- Si distingue entre confirmación atómica, falla condicional y un resultado desconocido tras una interrupción de red.
- Si utiliza
ClientRequestToken, una clave de idempotencia de negocio duradera y expresiones de condición correctamente. - Si tiene en cuenta la capacidad transaccional adicional, los límites de la API y la contención de claves calientes.
- Si los reintentos, compensación, reconciliación, métricas y consistencia entre regiones forman un solo diseño.
Preguntas aclaratorias
- ¿Están las tablas de pedidos, inventario y libro contable en la misma Región de AWS y límite de cuenta?
- ¿Se permite la sobreventa y el libro contable debe ser un registro inmutable de solo adición?
- ¿Puede el cliente consultar el estado final mediante una clave de idempotencia de negocio tras un tiempo de espera?
- ¿Podría ocurrir un reintento después de la ventana de validez del token?
- ¿Se requiere escritura de recuperación ante desastres entre regiones o es suficiente la atomicidad en una sola región?
Respuesta en 30 segundos
Crearía una clave de idempotencia estable para cada operación de negocio y usaría TransactWriteItems en una Región para crear el pedido, decrementar condicionalmente el inventario y escribir una entrada en el libro contable de manera atómica. La solicitud lleva un ClientRequestToken; el estado de negocio duradero y las condiciones evitan decrementos duplicados. Después de un tiempo de espera, lea por la clave de negocio antes de reintentar. Monitoree conflictos, fallas condicionales, capacidad y resultados desconocidos. Para el trabajo entre regiones, use eventos y reconciliación porque el límite atómico de la transacción es regional.
Respuesta detallada
Paso 1: Establecer los invariantes del negocio
Establezca el invariante: un pedido exitoso reduce el inventario una vez y crea una entrada en el libro contable. Utilice un operationId para los registros de pedidos y del libro contable, y requiera available >= quantity en el elemento de inventario. No use una marca de tiempo del cliente como clave única; los reintentos y el sesgo de reloj pueden crear operaciones duplicadas.
Paso 2: Componer las acciones de la transacción
Combine las acciones Put, Update, Delete y ConditionCheck en una sola solicitud TransactWriteItems. El Put del pedido requiere una clave faltante, el Update del inventario verifica una versión o cantidad disponible, y el Put del libro contable utiliza operationId como clave única. No opere sobre el mismo elemento dos veces en una transacción y respete los límites de acción y de tamaño de solicitud.
Paso 3: Construir dos capas de idempotencia
ClientRequestToken hace que la misma solicitud de transacción sea reintentable de forma segura durante su ventana de validez. Una clave de idempotencia de negocio persistida en el pedido y en el libro contable cubre un ciclo de vida más largo. Ambas deben identificar la misma operación; un reintento no debe inventar una nueva clave de negocio. Después de la ventana del token, lea el estado del negocio antes de reconstruir una transacción.
Paso 4: Separar la falla de un resultado desconocido
Los conflictos condicionales, los errores de capacidad y las fallas de validación generalmente proporcionan una ruta de falla accionable: devuelva un error de negocio o reintente con retroceso acotado según el error. Una conexión perdida tras el envío es desconocida; no revierta de inmediato el inventario. Lea el pedido, la versión del inventario y el libro contable mediante operationId, luego deje que la máquina de estados elija el reintento o la reconciliación.
Paso 5: Contabilizar el costo y las claves calientes
DynamoDB realiza lecturas o escrituras subyacentes para la preparación y confirmación de la transacción, por lo que el uso de capacidad es mayor que una sola escritura ordinaria. Estime el rendimiento a partir del tamaño del elemento, la concurrencia y la amplificación de reintentos, y fragmente el inventario caliente o utilice una cola de reserva. La WCU promedio es insuficiente; las fallas condicionales y los conflictos también consumen presupuestos de latencia y capacidad.
Paso 6: Manejar los requisitos regionales
La atomicidad de la transacción se aplica al límite de la transacción en la Región emisora. Si la analítica o una réplica vive en otro lugar, publique un evento que lleve operationId; los consumidores escriben de forma idempotente y la reconciliación encuentra vacíos o duplicados. Durante el retraso de replicación, un modelo de lectura remoto no es prueba de una confirmación de transacción inmediata.
Paso 7: Observar y recuperar
Registre el éxito de las transacciones, fallas condicionales, conflictos, limitación de tasa (throttling), recuento de reintentos, resultados desconocidos, capacidad por tabla y latencia de extremo a extremo. Utilice estados como PENDING, COMMITTED, RECONCILING y FAILED; un escáner maneja estados desconocidos y completa el libro contable o crea una cola humana. Correlacione los registros de solicitudes, elementos de tabla y eventos por operationId.
Respuesta modelo
Para cada pedido crearía un operationId estable y usaría TransactWriteItems en una Región para crear el pedido, decrementar condicionalmente el inventario y escribir un elemento en el libro contable indexado por ese ID. El pedido requiere una clave faltante, el inventario verifica su versión y available >= quantity, y el libro contable se deduplica de forma natural. La solicitud también lleva un ClientRequestToken estable. Una falla condicional devuelve un error de negocio explicable; un tiempo de espera posterior a la confirmación lee primero los tres registros por operationId en lugar de revertir ciegamente el inventario. Las estimaciones de capacidad incluyen el trabajo de preparación y confirmación transaccional, claves calientes y amplificación de reintentos. La propagación entre regiones utiliza eventos idempotentes y reconciliación en lugar de afirmar atomicidad entre regiones. Las métricas cubren conflictos, capacidad, resultados desconocidos y tiempo de recuperación de la máquina de estados.
Errores comunes
- Tratar un tiempo de espera como prueba de que la transacción falló y revertir el inventario inmediatamente.
- Generar una nueva clave de negocio en cada reintento, creando pedidos o entradas en el libro contable duplicados.
- Depender únicamente de
ClientRequestTokeny omitir la idempotencia de negocio duradera. - Ignorar los conflictos condicionales, los límites de transacción y la capacidad transaccional adicional.
- Tratar la replicación de tablas globales o una lectura remota como prueba de confirmación de transacción.
- No tener un escáner de estados desconocidos ni una ruta de reconciliación más allá de la inspección manual de registros.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Garantiza ClientRequestToken la idempotencia permanente?
No. Cubre la ventana de validez definida por la API. La idempotencia de larga duración requiere una clave de negocio y un estado final en el pedido, el libro contable o una tabla de operaciones.
Pregunta de seguimiento 2: ¿Debe reintentarse una falla de condición de inventario?
Si el inventario es insuficiente, reintentar no puede cambiar el resultado y debería devolver una falla de negocio. Un conflicto transitorio o una limitación de tasa pueden reintentarse con retroceso, la misma clave de operación y un recuento de intentos acotado.
Pregunta de seguimiento 3: ¿Cómo se decide el resultado tras un tiempo de espera?
Lea el pedido, la versión del inventario y el libro contable por operationId. Registros consistentes indican confirmación; la visibilidad parcial o el desacuerdo entra en RECONCILING, donde un flujo de trabajo elige la finalización o el manejo humano.
Pregunta de seguimiento 4: ¿Por qué no colocar escrituras entre regiones en una sola transacción?
La API no extiende la atomicidad a través de múltiples Regiones. Use eventos, consumidores idempotentes y reconciliación mientras documenta la ventana de consistencia eventual y el comportamiento de degradación.
Pregunta de seguimiento 5: ¿Cómo se localizan los conflictos de transacción?
Registre operationId, claves de elementos, versiones de condición y recuento de reintentos, luego agregue los conflictos por clave caliente. Un elemento de inventario con contención persistente puede necesitar fragmentación, reservas o asignación basada en colas.
Pregunta de seguimiento 6: ¿Cómo se prueba la ruta de resultado desconocido?
Descarte la respuesta después de que el servidor confirme la transacción para simular un tiempo de espera del cliente. Verifique la búsqueda, el reintento, las transiciones de estado, la deduplicación de eventos y la reconciliación para que el inventario y el libro contable nunca se apliquen dos veces.