Scaling FHIR with microservices
summary
Firely experiments split FHIR into microservices: a validation Lambda built from a precompiled conformance package to start in milliseconds; messaging via MassTransit switching between Kafka Azure Service Bus and a RabbitMQ cluster of four nodes; storage on MongoDB Atlas feeding indexers — originally 7 indexers reduced to 3 to keep up; transactions work by resolving conditionals and assigning IDs up front; the change stream to queue is a bottleneck so they publish DB changes into a scalable queue; search is eventually consistent while reads and validated writes remain immediate.
AI-written summary · about
chapters (9)
- 0:00Introduction and context
- 2:12Current FHIR server architecture
- 4:01Validation service as Lambda
- 11:53Microservices proof of concept
- 20:25Sidecar architecture design
- 23:59Messaging infrastructure choices
- 28:13Lessons learned and challenges
- 31:45Future migration and developer impact
- 33:10Q&A session
related talks
02h 10mLet's Build: Introduction Firely .NET SDK for FHIR
41mAdopting Microservices in Healthcare, Breaking Apart the Monolith
21mEvents with FHIR: a Simplified Way to Unify Health Data
29mMonolith to microservices transformation at Broadridge Advisor Solutions
45mMicro Services and Events: Friends or Foes?
48mChallenges in Implementing MicroServices
27mHow Micro-Service Patterns Change When the Database Scalable
31mDeploying Microservice Architectures with Cloud Foundry