Breaking it Down: Microservices Architecture for PHP Developers
- 1. Microservices Architecture for PHP Developers It’s not about the tech. It’s about the people.
- 2. Overview • What is (and isn’t) Microservices Architecture? • Why teams choose it • Talk about the “transitional phase” • The main pieces / building blocks we use at Givelify • Visual and code (PHP) examples • Tactical advice, things to watch out for Warning: You’re going to see lots of ants . Hope you like ants 😛 😛
- 3. Who am I? • Peter Meth • Software Architect at Givelify • Hail from Toronto, Canada • Writing, Fixing, Breaking software for 20+ years • Meetup organizer for 9+ years • Conference organizer for 6 years
- 4. Why this talk? • Microservices are often misunderstood or over-engineered • This talk isn’t about hype - it’s about clarity and teamwork • There are many architectural choices • Microservices aren’t always the right one • Recent criticism reminds us that complexity, cost, and team fit matter • Help shift how people think of microservices and the benefits • People think PHP & microservices is a misfit • I’ll show how we made it work with PHP in the real world
- 6. Before: Givelify in 2018 • Givelify: over a billion $ of annual donations • PHP 5.3 in production (4 years past EOL, latest was 7.2) • Legacy code we couldn’t safely upgrade • Testing was nearly impossible • Deployments often failed, outages were scary to fix • Changes were slow and fragile • Teams often blocked each other • Business was growing .. That’s good • Every change felt riskier .. That’s bad
- 7. After: Givelify in 2025 • Most services on PHP 8.3, some 8.4 + Laravel 11/12 • Upgrades are fast and easy • Frequent frictionless deployments, outages are rare • Most code is well-tested and safe to change • Teams move independently and quickly • Business still growing • Only now the tech is sustainable
- 8. What is Microservices Architecture?
- 9. Microservices Architecture in a Nutshell • Independent systems focused on a single responsibility • No strict rule on how small, just small enough to reason about • Each service has its own codebase, deployments, and database • Communication handled by APIs, gateways, or service discovery • Often coordinated using an event or message bus • e.g. Kafka, SNS, RabbitMQ • Each service is owned by one team end-to-end • Not limited to one tech stack • Services can be in PHP, Java, Node, Python, etc.
- 10. Mindset Over Recipe • Misconception: microservices = high-scale, high-speed, complex • Reality: real benefit is what it does for teams and people • Teams become more autonomous • Teams have better focus and become domain experts • It promotes structure, clarity, and ownership • It’s often simpler to understand the individual pieces • It’s not a recipe, it’s a mindset. There’s no “one right way”
- 11. Why Teams Choose Microservices • Because someone on the internet said it’s cool • Enable teams to move faster and work more independently • Improve clarity, ownership, and testability • Build and deploy with less coordination overhead • Scale parts of the system separately • Reduce the blast radius of bugs and deployments • Use different technologies in different parts of the system • Natural evolution of agile or Domain Driven Design • Because someone on the internet said it’s cool
- 13. Time For a Change • Most teams don’t start with microservices • Start with a monolith & transition to microservices • Both must coexist, often for years • This state is messy, but normal • Plan not just for end state but also for in-between • At Givelify this meant modified patterns, fallback APIs and creative workarounds • Not perfect, but it works & buys time for thoughtful change
- 15. Feel Free To Make Your Architecture Yours • No one-size-fits-all microservices blueprint • Don’t have to follow every internet best practice • Design around team strengths, user needs and capabilites • Build tools and processes that are comfortable and maintainable • Keep things consistent and predictable • Define rules that fit your culture & stick to them • or break them with care and documentation • Start small, gain confidence, learn as you go
- 16. Team Structure • Cross-functional. Scope is well defined • Think of all the roles needed to design, ship, support • Teams should be able to make decisions independently • Teams should not block each other • Each service belongs to a single team • Teams can own several services
- 17. The Pieces and How They Fit Together
- 18. Domain Services • Encapsulate business logic for a specific capability • Does not call other services directly • Publishes events when state changes • May consume events to trigger new actions or processing • May expose an API (for Gateways only—not other services) • Naming is important. Be consistent • Each service owns its own data * * Typical but depends on the implementation. More in this later
- 19. Authentication • We use JWT (JSON Web Tokens) to authenticate requests • Tokens are issued by a central Identity Service • Each service just needs to validate the token, not manage sessions or passwords • Lightweight, fast, and easy to implement across services • Helps keep services stateless and decoupled
- 20. Let me introduce my BFF • BFF = Backend for Frontend, one of several api gateway patterns • Each UI gets a Gateway tailored to its needs • Frontend communicates with a single api (like a monolith) • Gateway can call multiple domain services • Translates responses to frontend-friendly responses • Contains minimal logic, just enough to serve the UI • Gateways talk to domain services, not other Gateways Let me introduce my BFF (API Gateway)
- 22. Event Bus • Whenever important things occur an event is fired • Simple JSON messages that pass info among domain services • Allows coordination without tight dependencies • Publishers don’t know (or care) who’s listening • Consumers only care about the message contents • This enables autonomy, fault tolerance, and future flexibility • Also provides a replayable record of the events that occurred
- 24. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume
- 25. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume 🔑 JWT
- 26. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume 🔑 JWT
- 27. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume 🔑 JWT 🔑 JWT 🔑 JWT
- 28. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume 🔑 JWT
- 29. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume
- 30. Specific Gatewa y Donations Publishes: • Donation Succeeded • Donation Failed Donatio n Notifier Publishes: • Notification Sent Listens: • Donation Succeeded Authenticato r Publishes: • Logged In • Failed Login New Products / UI Specific Gatewa y BFF Gatewa y • BFF Gateway • JWT Auth • EventBus Publish • Domain Service • EventBus Consume
- 32. Domain Service / Event Bus Implementation (incoming request)
- 33. Domain Service / Event Bus Implementation (incoming request)
- 35. Domain Service / Event Bus Implementation (offline processor)
- 36. Database Per Service (Typical Approach) • Each domain service typically has its own database • Contains all the data needed to perform its responsibilities • Services should not directly query / access another service’s db • If a service needs external data, it subscribes to events and updates its own data store • Encourages loose coupling, autonomy, and resilience • Note: this is not the only database option!
- 38. Database Per Team (Givelify Approach) • Teams built around experiences (e.g. giving, giving partner, etc) • Each experience has shared db used by its domain services • Reduces db sprawl and simplifies ops and dev workflows • Cross-Experience data updates via MySQL views, not events • Views are a temporary measure. Goal is to replace them with event-driven sync
- 40. Advice for Keeping It Manageable • Define basic architectural rules early to avoid confusion / rework • Checklists help teams balance autonomy with consistency • Use consistent, predictable naming • Avoid tight coupling domain services • direct API calls, shared db*, etc • Shared libraries can introduce hidden dependencies • Library updates can have huge ripple effect • Use sparingly • Remember why you’re doing this • to help your teams and people
- 41. Wrapping Up, What We Covered • The challenges of life in the monolith • Why we chose microservices—and what it really means • The transitional state (and why it matters) • How we designed our architecture to fit our teams • Domain services, JWT Auth, Event bus, Gateways, Databases • Real-world implementation with code samples • Practical advice
- 42. Want To Dive Deeper? • microservices.io • Great reference to explore / understand common patterns • Laravel Microservices by Gary Clarke • Recently announced online course • Monolith to Microservices: Evolutionary patterns to transform your monolith by Sam Newman • Also available as an audiobook
- 43. Rate this talk • Helps organizers • Helps speakers • Helps attendees https://joind.in/talk/ cca97
- 44. The End of the Line @devopsmeth phpc.social/@pmeth petermeth pmeth@delvia.com