- Topic: a concept of grouping things together that are close to each other - Number of topics depends on the ecosystem - for example not all consumer groups might be interested in all events, having them go through the events they don’t care might not be ideal - Producers shouldn’t be too much coupled to the logic behind multiple applications/consumer groups, strive for the balance
not to publish: unless you only care about database replication or are building some archive service, don’t do paper-trail- versions style of serialization & publishing model.as_json etc. - this can lead to a “distributed monolith“
event with a payload containing things that will be useful for the consumers to do something with the event, so maybe amount, currency, payment time, transaction ID etc. - Events for activity tracking, metrics and analytics, e.g. “page_visited” with user’s ID, timestamp and URL of the page etc.
some data to be available in other services. Think more like HTTP Resources in REST API that don’t map 1:1 to a database, including sideloading (e.g. invoice together with its services in a single event instead of having separate events for invoice and services).
Companies - the actual users of the application - Topic 2: Invoices - everything related to the invoices, including services/items, customer’s data, amounts, payment terms etc. - Topic 3: Billing - whatever is related to charging Companies