Problem
Users working in a multilingual environment had to translate issue content and comments by copying them into external tools. It was slow, inconvenient and risky — business data left the controlled environment, and the workflow was fragmented across many steps.
Context
The solution extended a ticketing platform (Jira Data Center) in an enterprise organization with strict requirements around secret handling and preventing data leakage to uncontrolled services. The goal was in-place translation, without leaving Jira.
Requirements
- Translate selected issue fields and comments without leaving Jira.
- Secrets (keys, credentials) never in the plugin code or on the client side.
- Handle large content and many concurrent requests without blocking the UI.
- A controlled, auditable flow to the model service.
Role
I designed the overall solution and implemented its key parts: the translation plugin in Jira, a shared secure integration layer (bridge + secrets), and a serverless backend in AWS integrated with a language model.
Architecture
The design deliberately separates concerns: UI and domain logic in Jira, secret isolation in a dedicated bridge plugin, and heavy logic plus model access in the serverless layer.
Technologies
Jira plugin (Java, Active Objects) for UI, configuration and permissions; a separate bridge plugin with a local secret store (PKCS12) and a call service; AWS API Gateway + two Lambdas (authorization and logic) + Amazon Bedrock; secrets in IAM/Secrets Manager rather than in code.
Design decisions
- Plugin separation: a dedicated bridge plugin as a shared security layer for multiple integrations, instead of embedding secrets in every plugin.
- Thin backend over managed AI: translation logic as a thin serverless layer, the model as a managed service (Bedrock).
- Authorization decoupled from logic: a separate authorizer at API Gateway.
Trade-offs
- More components (plugin + bridge + serverless) means more deployment complexity, but a much smaller risk surface and better reusability.
- A managed model (Bedrock) means faster time-to-value and no model maintenance, at the cost of vendor dependency and service limits.
Technical challenges
- Large content exceeded the limits of a single model request.
- Many concurrent translations risked overloading the service and blocking the UI.
- The result needed to preserve fragment order and consistency.
Solutions
- Chunking of large payloads and reassembling the result in order.
- Asynchronous / multi-threaded processing with queueing and concurrency control (a parallelism limit) to avoid overloading the model service.
- A non-blocking UI flow — the user does not wait synchronously for the whole job.
Result
Translation became available directly inside Jira, without copying data into external tools. Secrets stayed out of the code and off the client, and the serverless architecture scaled request handling without maintaining any model infrastructure.
Lessons learned
- Extracting the secret layer into a separate component pays off with more than one integration.
- Concurrency control matters as much as the model integration itself — without it, “works for one” becomes “fails for ten”.
What I’d do differently today
- Add a cache for repeated translations and cost/token metrics per request.
- Consider a managed queue (e.g. SQS) instead of in-app queueing.
Interview talking points
- Why secrets went into a separate bridge plugin rather than the translation plugin.
- How chunking + a concurrency limit protect both UX and the model service.
- The “thin serverless backend over managed AI” trade-off vs. self-hosting a model.