Ethan Garofolo's wroclove.rb 2019 talk on the UI implications of microservices. Framed as a 'questions talk' rather than an answers talk (quoting Claude Lévi-Strauss: 'the scientist is one who asks the right questions'). Defines a monolith as a data model (cramming many different domains behind one user ID), explains why simply splitting a monolithic data model across HTTP turns method calls into distributed-computing problems (the 'distributed monolith'), and redefines services by autonomy: services don't have GET APIs (that's just a database), don't depend on others, are oblivious to the rest of the system, and communicate via asynchronous messages — events (past-tense facts) and commands (imperative intent). Introduces the architecture pieces: services (action-packed 'lightning bolts'), an application layer (Express/Hapi/Django/Rails), a message store (Eventide, Rails Event Store, the Event Store project), aggregators producing read models / materialized views, and pub/sub messaging where publishers and consumers are mutually unaware. Uses a zebra/texture-map metaphor to warn that mapping MVC-CRUD thinking onto services produces a 'monstrosity' and articles like 'The Majestic Monolith'. Presents three UI patterns for an eventually consistent system, demonstrated with a 'video tutorials' sample app: (1) sometimes nothing is enough — don't wait (e.g. YouTube view counts); (2) stalling for time — hide async processing behind a static screen (e.g. 'check your email to confirm'); (3) embrace the evented model — accept bad input, record it as an event, then show different read-model views to different users (content creator sees the validation error; viewers keep the previous valid name). Emphasizes polling by command ID so the UI knows when a command has processed. Closes with recommendations to design the user experience first with business/UX, elevate validations into the domain, and read the Eventide project. Q&A covers when a command is considered processed (when the service produces its event), the UI complexity of per-field validation (task-driven UIs keep forms small), and migrating legacy data by seeding 'legacy foo imported' events as the start of new streams.