Events, lifecycle and media

Three kinds of background work, each run through TessariDB: events through a topic, lifecycle and media through queues that hand each piece of work to one node at a time.

Notifications

PutBucketNotificationConfiguration accepts queue configurations. The default destination needs no setting: arn:tessaridb:sqs:::tessaridb is the metadata store's own s3_notifications topic, read by a consumer with a topic group. A destination the operator declared in TESSARIDB_S3_NOTIFY_TARGETS (a Kafka topic or a webhook) is the alternative, named arn:tessaridb:sqs:::<id>, never by an address, so a bucket administrator cannot point the server at a host of their choosing.

Events: s3:ObjectCreated:* (Put, Copy, CompleteMultipartUpload), s3:ObjectRemoved:* (Delete, DeleteMarkerCreated) and s3:LifecycleExpiration:* (Delete, DeleteMarkerCreated), with a prefix and a suffix filter.

• Every change in a configured bucket is recorded in TessariDB in the change's own commit and delivered as an S3 event record. The sequencer is the event's position.
• Into the topic it is delivered once per event; to Kafka (keyed by bucket/key) or a webhook at least once, from any node.
• A refused delivery is retried after a growing wait and given up to a dead-letter topic after 8 tries.
• An undeclared destination, an unsupported event or overlapping rules are refused InvalidArgument; topic, function and event-bus configurations NotImplemented.

Lifecycle

Rules by prefix with Expiration (days, date, ExpiredObjectDeleteMarker), NoncurrentVersionExpiration with NewerNoncurrentVersions, and AbortIncompleteMultipartUpload. Transitions and tag or size filters are refused NotImplemented.

Rules are applied by a background pass on every node: each bucket with rules is handed to one node at a time through a queue in TessariDB and is due again an hour after each pass. A period runs to the next midnight UTC after its days are up. A current object is expired only while it is still the write that was judged, leaving a delete marker in a versioned bucket.

Media renditions

A bucket's media rules say which content types under which key prefix get which renditions. They are set in the console by whoever configures the bucket and seen by whoever reads it.

• Images and poster frames are fitted into the listed sizes (150 to 3840 px), never enlarged, as JPEG, PNG, WebP or AVIF.
• Videos become MP4 (H.264 High, 4:2:0, AAC, index first) or WebM (VP9, 4:2:0, Opus) with the shorter side at the listed height (360p to 2160p), never enlarged.
• Renditions are ordinary objects under <key>.renditions/; a rendition never gets renditions.

Every node plans the objects the metadata store's media group hands it into tasks in the media_images queue; any node's workers render them (TESSARIDB_S3_MEDIA_WORKERS, 2 by default). Video work runs only on nodes given an ffmpeg (TESSARIDB_S3_FFMPEG), as its own process, stopped after 50 minutes; the published image carries none. A failed task is tried again after a growing wait and stays listed in the console after five tries.