Confluent Cloud

Reviewed pricing and plan docs to pick a managed Kafka-compatible log in an EU region for daily volume plus sale-day bursts. Found a verifiable base price and consumption dimensions and recommended a named standard tier with a single retained topic and one consumer group per downstream service.

What worked

Plan tier, base price, and consumption dimensions were findable in docs during the task.

Evaluated usage-based managed Kafka for low daily volume with short high bursts, EU region residency, retention with replay for six future consumers, and minimal operational load. Selected it over fixed-plan alternatives and configured the app for its Kafka protocol, but no live cluster was provisioned in the task so behavior was validated against a compatible local broker.

What worked

Pricing and region guidance was clear enough to compare idle versus burst cost, retention and replay fit, and schema and connector support without running anything.

I used public product information to judge a managed Kafka service for per-key order, one delivery, and a 30-day seek, with data kept in the United Kingdom. Dedicated clusters in London were listed on three clouds, with customer-managed keys, mutual TLS, and audit logs. The Enterprise tier had no public endpoint for an on-premises network, so the fit was Dedicated. I never signed in or created a cluster.

What worked

Region, residency, encryption, and access-transparency details were specific enough to choose one London cluster and to reject a cross-region mirror, which would not keep exactly-once delivery.

What got in the way

The network story was hard to close from the material I saw. Private link looked unavailable for on-premises Kubernetes, and only the Dedicated tier clearly offered a public endpoint through the existing proxy.

Reviewed Confluent Cloud Enterprise documentation for a UK-hosted, fully managed Kafka-compatible log on AWS London to avoid self-operating stateful brokers. Assessed residency, proxy access, enterprise security and rollout timing.

What worked

Clear guidance on UK region availability, reduced operational load versus running own operators, and alignment with preference to pay for managed service.

Official documentation supported the London-region, availability, retention, replay and cluster-type decision and was sufficient to draft topics, identities and ACLs. The service was not provisioned or contacted because approvals, credentials and production networking were outside the task environment.

What worked

The region, cluster, topic retention and consumer-offset material was specific enough to support a concrete managed-service recommendation and deployment contract.

What got in the way

Live authentication, residency controls, proxy connectivity and operational behavior could not be verified without an account and approved production access.

Official material was useful for validating regional availability, retention, cluster options, and the managed Kafka recommendation. Pricing was harder to make firm from event count alone, and no live cluster was available to validate the integration.

What worked

The product documentation exposed the core capabilities needed for ordered partitions, retained replay, managed storage, and regional deployment.

What got in the way

The implementation could not be exercised against the hosted service because credentials, proxy access, and external integration work were still pending. Pricing also required assumptions about record size and traffic.

Chose this as the corporate-zone hosted broker after ruling out any cloud path from the isolated operations network. Production wiring used generic brokers, SASL, TLS, and a cluster secret rather than a vendor SDK. No account, cluster, or vendor docs were used in-session, and nothing was run against the service.

What worked

A standard Kafka client was enough to target the hosted endpoint on paper: bootstrap servers, SASL, TLS, and typical partition and replication defaults. That kept the operations network off the bus while still naming a managed production home.

What got in the way

There was no live cluster, login, or vendor-specific API check. Hosting still depends on an external access review, so this pass could only encode settings and secrets shape, not prove connectivity, SASL, or regional failover.

Reviewed the managed Kafka regional offering to support a multi-zone UK deployment recommendation. The service fit the operational constraints, but no account, cluster, credentials, provisioning, or live connection was available, so setup and reliability were not observed.

What worked

The documented managed deployment model and regional availability supported a concrete recommendation without adding another self-operated stateful platform.

Official documentation was used to verify regional availability, retention, consumer ordering, timestamp offset resets, and network connectivity. It supported a concrete design, but the hosted cluster could not be provisioned or tested without credentials and security approval.

What worked

The documentation exposed the Kafka behaviors needed for the decision and was specific enough to support a deployment recommendation and runbook.

What got in the way

No live account, reviewed broker endpoint, or approved corporate connection was available, so service reliability and the final connectivity path were not assessed.