Confluent Platform and Cloud Components
Schema Registry
Schemas are registered under a subject and assigned a globally unique ID per version. The default subject naming strategy is TopicNameStrategy (<topic>-key, <topic>-value); alternatives are RecordNameStrategy (schema per record type, good for shared event types) and TopicRecordNameStrategy (per topic+type).
Compatibility is enforced at registration: with BACKWARD (the default), consumers using the new schema can read data written with the previous one - add optional fields with defaults, or remove fields. FORWARD means old consumers can read new data - adding fields is safe. FULL allows only adding or removing fields that have defaults. Adding -transitive (e.g., FULL_TRANSITIVE) checks against all prior versions, not just the latest - a frequent trap when a change passes locally but fails in a shared registry.
Platform and cloud
Beyond the brokers: Kafka Connect (managed connectors in Cloud), ksqlDB and Flink on Confluent Cloud for stream processing, Confluent Stream Catalog/lineage, data contracts, and client quotas. Security and governance run on ACLs (self-managed) and RBAC (Cloud: organization/environment/cluster scopes), with service accounts and API keys for applications, plus audit logs.
Rule of thumb
Before changing a schema, ask: who reads this? If the answer is "downstream consumers I don't control", your change must be backward compatible, and production should set auto.register.schemas=false so accidental schemas fail fast rather than polluting the registry.