The final Udi presentation of the conference.

Key takeaway - pubsub is generally the best way to build your services - think of everything as long-running. Instead of having your billing service ask your customer service for their current address every time it needs it, have the billing service cache customer data, and subscribe to the customer service to receive updates. The important thing to note here - this is NOT replication. In replication, there is no authoritative source of data - all sources are authoritative. In this scheme, the customer service is the system of record for customer data, and is responsible for it. If the billing service were to encounter a discrepency in customer data, it would ask the customer service for the current data, and use that. There is never a conflcit - the customer service is always right (sorry, that's almost a pun).

As you design your system, think about how it worked before it was automated. An order was faxed in, and handled by various people. Eventually, good would be shipped and a bill sent to the customer. Each of these steps in the workflow are just a process in the business, just now they are automated to improve efficiency (hopefully). Services are not APIs in the RPC style of thinking - they are different parts of the business, and have their own responsibilites. They don't care about what happened before in the workflow (beyond what concerns them) and they don't care what happens after them. When they finish their work, they post events to whomever is subscribed, and let the next processes figure out what to do.