Crafting a microservice that fits your needs

This blog is based on Haylee Millar's talk at the Symfony 2024 conference. Haley is a Product Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content.

When faced with an aging system that needs new features, many development teams find themselves at a crossroads. Do you patch the old system and risk technical debt, or do you take the leap into microservices architecture? This is the story of how one team made that decision and what they learned along the way.

What is a microservice?

A microservice is an independent service that talks to other services over APIs. Each service is loosely coupled and can be built, deployed, and scaled on its own. It does not have to own a database, but many do. The key is separation, so that one service can be changed without forcing changes across the entire app.

Think of it like a restaurant kitchen. In a monolithic approach, one chef handles everything – appetizers, main courses, desserts, and beverages. With microservices, you have specialized stations: a salad chef, a grill master, a pastry chef, and a bartender, each expert in their domain but coordinating to serve complete meals.

Pros

• Scalability: Add resources to services as needed, rather than scaling the entire app.
• Speed: Smaller codebases facilitate faster development and deployment.
• Technology freedom: Pick the stack that fits each service. You do not have to use the same language or framework everywhere.
• Failure isolation: One service can fail gracefully without taking down the entire application. You can degrade performance rather than go offline.

Cons

• Complexity: More services mean more moving parts. Network calls replace in-process calls. Data may reside in more than one location, which makes consistency more challenging.
• Debugging: It can be challenging to pinpoint the source of a problem in a distributed system. Strong logging, request IDs, and distributed tracing help.
• Security surface: More services and more network paths mean more to secure.

When to choose microservices

Microservices can be a suitable fit when multiple teams require autonomy, when different features evolve at varying speeds, and when you need independent development, deployment, and scaling for specific parts of the application. They are not the only answer. There are usually several ways to solve a problem. Select the approach that best suits your needs and constraints.

The real problem we had to solve

Our team owns account management. We were running an internal site built on a Drupal monolith. We planned to retire it, but we had an immediate issue to solve: user abuse on the product.

We could have added new anti-abuse features to the Drupal app. We chose not to. Reasons:

• We did not want to add weight to a system we planned to retire.
• We wanted to move quickly without being constrained by Drupal-specific requirements.
• We already had services outside of Drupal that integrated with it, like authentication and organizations.

We proposed a new microservice for implementing anti-abuse logic. It became the popular path in our discussions.

The service we built: KYC

We created a Symfony microservice called Know Your Customer (KYC). KYC checks customer identity and risk. We started deliberately small so we could ship quickly and learn.

Starting small and smart

We focused on five building blocks:

• User data sync ensured the service had the necessary facts.
• A user score endpoint for the support team.
• Staff verification endpoint and the ability to block a user if abuse is detected.
• Grant lists to let internal staff test and bypass when needed.

We kept ownership clear. KYC calculated a score, but it did not decide to limit resources. Our accounts service pulled the KYC score and decided whether to continue or halt a user action.

The stack and tools choices

• PHP with Symfony framework, so we could focus on logic rather than writing everything from scratch.
• PHPUnit for testing.
• GitLab CI/CD for continuous integration, delivery, and automatic deployment.
• A scheduler for sync jobs and grant lists.
  Common bundles and libraries: JOSE framework, LexikJWTAuthenticationBundle for JWT, CORS, Doctrine, and Doctrine Migrations.

From version 1.7 onward, we added Symfony Messenger to sync IP scores from an external service.

Hosting and workflow

We hosted the service on our platform since we are a platform-as-a-service company. For teams curious about deploying Symfony, we demonstrated how to set up a demo app using the Symfony command line and how to initialize an existing project, add the necessary files, and deploy.

How it evolved

We finalized the KYC design in June 2022. It took approximately six months to implement after the stakeholder agreement was reached. Since then, we have kept a steady release pace. At the time of the talk, we were at version 2.23.

What changed between 1.0 and 2.23:

• More score types: overall risk, known customer, free trials, and testing.
• Payment profiles that help decide which payment methods to allow.
• External risk checks for IP and payment method.
• Early steps toward machine learning.
• Ongoing work to make the user score logic richer.

What worked well

• Fast iteration: KYC is a small service and not part of the monolith, allowing us to release quickly. We can push multiple releases in a day without risking the entire application.
• More features sooner: The speed enables us to add useful features for the support team and steadily improve the scoring logic.
• Up-to-date stack: Symfony and PHP stay current without being tied to an older system we plan to retire.
• Resource savings: Faster development and targeted scaling result in time and cost savings.

The challenges

• Data sync: Keeping data in sync with the source of truth requires careful work.
• Complexity for support: A new service introduces new paths for ticket management. Support now handles cases where users are blocked, which changes workflows.
• Distributed System Overhead: Managing multiple services introduced operational overhead that didn't exist with the monolithic system.

Q&A highlights

Which tools helped most for microservices?
The biggest win was choosing Symfony. It is lightweight and modular, and we are already familiar with PHP. The bundles provided us with the building blocks we needed without requiring heavy custom tooling.

Do you version your API endpoints, such as/v1 and /v2?
We have not done that so far, but it is a good idea to consider.

How did you handle privacy?
We avoid storing personal data in KYC when it is not necessary. Instead, we use unique IDs to look up personal information in the accounts service when required. During sync, we ensure that we only move what is necessary.

Do you share code across Symfony projects?
Not today. We started simple with the standard bundles. Shared packages could make sense later if the need grows.

What about the Drupal monolith?
It still exists. We are moving in steps. You cannot rewrite everything at once. We piece out parts and reimplement them in a more modular way. Where possible, we seek existing products rather than developing everything from scratch.

How did you handle external service sync and uptime?
Keeping user data up to date was the primary challenge. We added refresh logic and ensured that scores are calculated as soon as accounts are created. We use a syncing worker and an asynchronous path behind it, allowing us to cope when a score is not available immediately.

Takeaways you can use

• Start small. A thin slice with clear ownership can deliver value quickly.
• Keep the decision point close to the domain. Let scoring reside in one service and enforcement reside in another, if that fits your architecture.
• Invest in logs, request IDs, and tracing early. They pay off the first time a cross-service bug appears.
• Plan for sync. Know your source of truth and design refresh paths from day one.
• Expect some support change. New services often alter the flow of tickets.

Microservices are not magic. They are one way to move faster when teams need autonomy and parts of your system change at different speeds. For us, carving out KYC as a microservice allowed us to ship anti-abuse features quickly, keep our stack current, and avoid adding weight to a monolith that we plan to retire.