Yes this is great — the burr s3 implementation was th simplest possible
one.

There are some classes/structuress for pluggability — might be worth a look
over to evaluate it and see how we can update the interfaces/how much we
need to?

On Sat, Feb 21, 2026 at 10:27 AM Stefan Krawczyk <[email protected]>
wrote:

> Hi Vaquar,
>
> This sounds great. The only consideration from my perspective is to make
> sure we enable a pluggable architecture and ensure that dependencies are
> optional and only needed for this particular server code path.
>
> I'll take a closer look later, but at first glance this seems directionally
> correct.
>
> Cheers,
>
> Stefan
>
> On Sat, Feb 14, 2026, 11:08 PM vaquar khan <[email protected]> wrote:
>
> > Hi Community,
> >
> > I wanted to open a discussion regarding the current state of running Burr
> > on AWS and propose an architectural roadmap to improve enterprise
> > readiness.
> >
> > While the local development experience is excellent, we encounter
> > significant friction when deploying to production environments on AWS.
> > Specifically, the polling-based telemetry introduces an observability
> > latency of 30–60 seconds, which disrupts the debugging loop,particularly
> > for human-in-the-loop workflows.
> >
> > Additionally, I’ve observed fragility in our persistence layer
> > (specifically *UnsupportedOperation*: not seekable errors with S3
> streams)
> > and identified a need to reduce the boilerplate required for Amazon
> Bedrock
> > integrations.
> >
> > *Proposal: Cloud-Native Architecture (BIP-42)*
> >
> > To address these gaps, I have drafted a comprehensive design proposal to
> > transition Burr toward an *Event-Driven Architecture*.
> >
> > *Key Highlights:*
> >
> >    -
> >
> >    *Event-Driven Telemetry:* Replace S3 polling with an SQS + EventBridge
> >    pipeline. This aims to reduce UI latency from ~60s to *<200ms*.
> >    -
> >
> >    *Reliable Persistence:* Implement a SeekableStreamAdapter that
> >    intelligently buffers S3 streams (using RAM with a disk spillover),
> >    resolving the serialization failures.
> >    -
> >
> >    *Native Bedrock Integration:* Introduce a standard BedrockAction class
> >    to abstract implementation details (streaming, guardrails, throttling)
> > and
> >    standardize usage patterns.
> >    -
> >
> >    *Infrastructure as Code:* A canonical Terraform module to provision
> this
> >    securely (VPC-native, private subnets), directly addressing *GitHub
> >    Issue #391*.
> >
> > *Review & Feedback*
> >
> > I have detailed the full technical specification in the document below
> and
> > cross-posted it to GitHub Issue #391.
> >
> >
> >    - * Proposal Document:*
> >
> >
> https://docs.google.com/document/d/1mZeJz1ERBpBlhQ8uXtsmoiuuiwlrVdUETBdFpFh1IoQ/edit?tab=t.0
> >    -  *GitHub Discussion:* https://github.com/apache/burr/issues/391
> >
> > I am particularly interested in feedback from those running Burr in
> strict
> > security environments.does the proposed Terraform module structure align
> > with your deployment constraints?
> >
> > Regards,
> >
> > Vaquar Khan
> >
> > Senior AWS Architect
> > *Linkedin *-https://www.linkedin.com/in/vaquar-khan-b695577/
> > *Book *-
> >
> >
> https://us.amazon.com/stores/Vaquar-Khan/author/B0DMJCG9W6?ref=ap_rdr&shoppingPortalEnabled=true
> >
> > *GitBook*-
> https://vaquarkhan.github.io/microservices-recipes-a-free-gitbook/
> > <
> https://us.amazon.com/stores/Vaquar-Khan/author/B0DMJCG9W6?ref=ap_rdr&shoppingPortalEnabled=true*GitBook*-https://vaquarkhan.github.io/microservices-recipes-a-free-gitbook/
> >
> > *Stack *-https://stackoverflow.com/users/4812170/vaquar-khan
> > *github*-https://github.com/vaquarkhan
> >
>

Reply via email to