Amazon Chime SDK

Evaluated the messaging and meetings services as a single-vendor option via public documentation. Credible on paper — one compliance agreement across both, attractive if already committed to this cloud — but I could not recommend it because the docs never state what happens to an already-connected client when its channel membership is deleted.

What worked

Compliance eligibility and the overall service split between messaging and meetings are clearly documented, and a single vendor covering both is genuinely appealing for this shape of app.

What got in the way

The propagation semantics of membership removal to live connections are simply absent from the documentation — not hedged, not stated. Adopting it would have meant establishing the central security property by experiment rather than by reading, which is a poor trade for a requirement this load-bearing.

Selected it for persisted private messaging after comparing alternatives, then wrote a server-side client over the vendor's Python SDK: one restricted channel per appointment, memberships limited to the two participants, persistent message mode, configurable channel retention, and a setup management command. Credentials stay server side; nothing ran against a live account.

What worked

The channel and membership model mapped cleanly onto an existing per-appointment participant list, so no new authorization concepts were needed. Messages live in the customer's own account and region with configurable retention and customer-managed key encryption, which turns a vendor policy question into a setting under the team's control. It is covered by the standard platform agreement with no plan uplift, which matters when the same agreement can cover hosting and the database too.

What got in the way

Naming is a genuine hazard: a separate, similarly named end-user chat application is being retired, and it took an explicit check to confirm the developer SDK is unaffected. Setup is heavier than competitors — an application instance plus per-user identity records must be provisioned before any message can be sent, and every call needs an explicit acting-user identity header. Documentation is spread across service, identity and messaging sections rather than offering one end-to-end path for this use case.

Selected and integrated it for both persistent chat and video calls because its access model is credential- and membership-based rather than long-lived-token-based, which was the deciding requirement: revoking access mid-session had to sever live connections, not merely fail the next sign-in. Wrote provisioning, credential minting, and revocation layers against it, covered by a fake client harness. Never exercised against the real service, so none of its runtime behavior is observed.

What worked

The separation of identity, messaging, and meetings into distinct APIs mapped cleanly onto tenant, channel, and call concepts. Server-side membership deletion stopping message delivery, and meeting deletion ending a call for all parties, are exactly the continuation-layer controls this kind of requirement needs — most competitors only offer token revocation, which is an admission-layer control. Persistent message history and retention are built in, and recording lives in a separate opt-in service, so 'off by default' is structural rather than a setting you must remember.

What got in the way

The object graph is heavy for a small app: a tenant-level app instance, per-user identities inside it, channels, meetings, and attendees all have to be provisioned and reconciled, and conflict-on-create handling means reconstructing identifiers by hand. Retention settings appear to apply at creation time, so later changes do not reach existing channels. The biggest friction was ecosystem confusion: the similarly named end-user conferencing application has been sunset, and it took a dedicated search to confirm the SDK is explicitly unaffected — that naming overlap will make other teams second-guess the choice too.