Real-world constraints often impact how we build digital services. This is especially true for enterprise APIs in regulated industries that transmit sensitive data across jurisdictions. Constraints around how data is managed can easily slow progress — but it doesn’t have to be that way.

At Platform Summit 2025, Yinka Omole will share tips for designing APIs amidst conflicting constraints.

At Platform Summit 2025, Yinka Omole, a lead software engineer at Personio, will be speaking about leveraging these types of corporate and regulatory constraints as an architectural advantage. For him, it requires more forethought further upstream in the API design process than usual, avoiding universal policies for all data types, and storing rules as configurations.

Right before the conference kicked off, I caught up with Omole to learn more about his background and upcoming session. Read on for his interesting cross-domain perspective from his work in financial and HR systems, and if you’re at the Platform Summit, definitely catch his session!

Interview with Yinka Omole

We’re thrilled to have you at the Platform Summit this year. Could you share a bit about your background and your work with APIs?

I’m a Lead Engineer at Personio, where I work on payroll systems serving over 15 thousand companies around the world. Before this, I was a VP at Goldman Sachs, building digital onboarding platforms and transaction banking APIs.

An interesting thing about my work with APIs is the cross-domain perspective I have. I’ve seen how financial services and HR tech tackle similar constraint problems (regulatory compliance, serving enterprise customers, audit requirements), but with different approaches. That diverse perspective across highly regulated industries has shaped how I think about API design.

What challenges are API-heavy large enterprises facing today when it comes to regulatory compliance?

The biggest challenge isn’t a single regulation, but rather the combination of various, sometimes conflicting requirements. For example, privacy requirements could demand data minimization and deletion, but financial regulations in other jurisdictions require multi-year audit retention on the same service for the same product.

Many enterprises handle these constraints and conflicts reactively. They build the API first, then keep trying to retrofit compliance as an afterthought. That’s expensive and often means rebuilding core architecture. The organizations that do it well treat constraints as first-class design inputs from day one.

How do you approach designing APIs that remain flexible to those constraints while still being highly performant and scalable?

I figure out which constraints and requirements I have, then map out which of them actually conflict with each other. Not just list all requirements, but map where they pull in opposite directions.

Then I look for architectural decisions that let me satisfy both. Sometimes that could be temporal separation (such as doing compliance checks asynchronously, and reconciling afterward to ensure 100% coverage). Sometimes it could be logical separation, and sometimes it’s moving the constraint to a different layer entirely.

The key is not trying to satisfy everything equally. You pick what’s non-negotiable, then design around those hard constraints first. Performance and flexibility come from being clear about what you’re not going to compromise on, and the core metrics that you need to pay attention to.

In your experience, what have been the key enablers of success for APIs that achieve widespread adoption and usage?

Making it easy to get started without understanding all the complexity. Developers should be productive immediately, not after reading documentation for hours.

Good documentation that explains the “why” behind design decisions also helps. When developers understand what constraints you’re navigating, they make better integration choices and have more realistic expectations.

Finally, stability. APIs in regulated environments can’t break things frequently. Once people integrate with payment or payroll systems, they’re not eager to change them. So you need compatibility strategies that last years, not months.

What are some design-time techniques for handling the headaches of serving data across multiple restrictions? How does smart API architecture help address those challenges?

One technique that’s useful is to separate your data based on sensitivity early. Not all data needs the same protection. Employee names need encryption and careful handling. Department names can be cached aggressively. When you treat everything the same, you either over-protect and kill performance, or under-protect and create compliance risks.

Another really useful technique is to store rules as configuration/data, not code. When business logic varies by jurisdiction, making it data-driven means adding a new country becomes a configuration exercise instead of risky code changes across multiple services.

Do you have any advice on choosing the appropriate API design style or format for the job at hand — whether REST, GraphQL, event-driven architecture, gRPC, or others?

It really comes down to your hardest constraint and what you can’t compromise on.

For example, if you need strong HTTP caching and your data maps well to resources, REST makes sense. Many companies also use this because the tooling ecosystem is mature and well-understood.

If you need audit trails and can accept eventual consistency, event-driven works well. A lot of compliance-heavy operations don’t actually need synchronous responses, and events give you the audit trail you need for free here.

For internal services where you control both ends and want strong typing, gRPC could work really well. It would be a different conversation, and gRPC might not work as well for external APIs where you don’t control the client.

Pick the technology that makes your hardest constraint easy to satisfy!

Have you been to Stockholm before? If so, what do you like most about it? If not, what are you most looking forward to?

I haven’t been yet, but I’m really looking forward to it! I’ve heard great things about the Old Town, the music, food, and the city’s approach to urban design. Also curious about the tech scene there!

What are you most excited about at the Platform Summit this year? Beyond your own presentation, are there particular themes, topics, or speakers you’re eager to learn from?

I’m curious about how practitioners are handling AI agents in production APIs. There’s a lot of hype around AI tooling right now, and I’m curious to see how people are actually implementing it in enterprise apps and APIs.

Also looking forward to learning from the community and meeting other people. I’ve found that usually the technical challenges we face aren’t as unique as we think they are, and it’s always useful to see how other people solve similar problems.